Timercpp: JavaScript-like setTimeout and setInterval for C++(github.com)
github.com
Timercpp: JavaScript-like setTimeout and setInterval for C++
https://github.com/shalithasuranga/timercpp
32 comments
I feel like there is a more constructive way to outline in which ways this solution might need to be improved to be suitable for various real-world use-cases, without focusing on whether this submission qualifies as HN content.
[deleted]
It has the same syntax as JavaScript, but unfortunately C++ is quite a different language. As C++ has neither compiler check for lifetimes nor garbage collection, this would be very easy to misuse in practice.
The Timer requires anything captured by the lambda to still be alive by the time the function is called. This may be obvious in C++, but it's still dangerous.
Even trying to use this as a set-and-forget-timer without any captures to work around this gotcha (like the example just printing stuff) won't work as the Timer object itself also needs to stay alive until the function is called. Do it further down the stack and the Timer is long destroyed when its function is supposed to run.
The Timer requires anything captured by the lambda to still be alive by the time the function is called. This may be obvious in C++, but it's still dangerous.
Even trying to use this as a set-and-forget-timer without any captures to work around this gotcha (like the example just printing stuff) won't work as the Timer object itself also needs to stay alive until the function is called. Do it further down the stack and the Timer is long destroyed when its function is supposed to run.
agreed, it is dangeorus if newbies try to use this
If it was only newbies doing such kind of errors. :\
It's missing `clearInterval(int)`, and these replicas return void instead of an ID that I can use to nuke the execution.
I can't quite understand what this brings that I wouldn't find from a std::thread constructor, besides less available documentation?
I can't quite understand what this brings that I wouldn't find from a std::thread constructor, besides less available documentation?
This setTimeout implementation has very different semantics compared to Javascript.
The main issue is it creates a thread per invocation instead of using an eventloop.
The main issue is it creates a thread per invocation instead of using an eventloop.
Exactly. And the eventloop that is available to a C++ application will differ completely depending on framework/platform. The only thing common to all platforms is that a thread is most likely to be the wrong way to do this.
Seems like a very useful short snippet for creating threads without having to learn a new threading API coming from a JS background.
It seems to me like it would be more useful however to implement these functions using a queue and run loop so that we don't have to worry about hard-to-trace race conditions, etc.
It seems to me like it would be more useful however to implement these functions using a queue and run loop so that we don't have to worry about hard-to-trace race conditions, etc.
Thats basically what asio's timer do: https://www.boost.org/doc/libs/1_63_0/doc/html/boost_asio/ex...
The ioservice contains the event loop that schedules the timers and dispatches the callbacks in the same thread.
> so that we don't have to worry about hard-to-trace race conditions, etc
Seems to me that something like 50% of clientside Javascript coding is "worrying about hard-to-trace race conditions", so maybe that's a feature, not a bug.
Seems to me that something like 50% of clientside Javascript coding is "worrying about hard-to-trace race conditions", so maybe that's a feature, not a bug.
Really? I thought Javascript was single threaded, aside from webworkers?
you don't need parallelism in order to create deadlocks or race conditions
I'm sorry but I'm not sure how a single threaded program can have race conditions? Surely the very definition of a race condition excludes the possibility? Or are our definitions different?
The event loop stops being deterministic if you start triggering events based on a clock. Or if you have calls blocking on external resources with unpredictable timing.
Say, you have a code like this:
Say, you have a code like this:
asynchronously doA();
blockReadingFile();
doB();
In general async executions really are big sources of race conditions in single threaded program. JS avoids this problem by blocking/queuing tasks until the current task is done but this is not the case in most lower-level environments.
1. Reentrancy. Flow of tasks can be interrupted by hardware interrupts and OS signals. In that case race conditions can happen by interrupt handlers. Bare metal embedded system programmers often have big headaches because of this.
2. JS implementations and JS API design can have race condition bugs. So JS API designers have to consider it. One of example is because of the order of queuing tasks/handlers. [1]
[1]: https://github.com/w3c/mediacapture-record/issues/150#issuec...
1. Reentrancy. Flow of tasks can be interrupted by hardware interrupts and OS signals. In that case race conditions can happen by interrupt handlers. Bare metal embedded system programmers often have big headaches because of this.
2. JS implementations and JS API design can have race condition bugs. So JS API designers have to consider it. One of example is because of the order of queuing tasks/handlers. [1]
[1]: https://github.com/w3c/mediacapture-record/issues/150#issuec...
Where did he mention ”parallelism”?
It is...
Javascript isn't single threaded. Callbacks happen asynchronously, and coupled with a synchronous DOM this means race condition central.
> Callbacks happen asynchronously,
asynchronicity and parallelism (threads) are two entirely different concepts. Most GUI systems except BeOS's are asynchronous on a single thread. When you code in node you just have one big hidden while loop that does
asynchronicity and parallelism (threads) are two entirely different concepts. Most GUI systems except BeOS's are asynchronous on a single thread. When you code in node you just have one big hidden while loop that does
while(true) {
doPostedEvents();
}
> asynchronicity and parallelism (threads) are two entirely different concepts
They are. However, in the browser resources (such as scripts) will be loaded using multiple threads. Javascript will be executed on one thread at a time, but this execution will switch to another context at the appropriate breakpoints.
Javascript in the browser is a multithreaded cooperatively multitasking system.
They are. However, in the browser resources (such as scripts) will be loaded using multiple threads. Javascript will be executed on one thread at a time, but this execution will switch to another context at the appropriate breakpoints.
Javascript in the browser is a multithreaded cooperatively multitasking system.
> However, in the browser resources (such as scripts) will be loaded using multiple threads.
Are you sure about this ? I could not find anywhere something saying that the main JS execution would switch threads - and even if it did, it would not impact the observable behaviour of your JS code anyways. Everything I could find on google says "JS is single-threaded" (except for web workers of course).
Is this page wrong ? : https://itnext.io/how-javascript-works-in-browser-and-node-a... and do you have an example of problematic code ?
Are you sure about this ? I could not find anywhere something saying that the main JS execution would switch threads - and even if it did, it would not impact the observable behaviour of your JS code anyways. Everything I could find on google says "JS is single-threaded" (except for web workers of course).
Is this page wrong ? : https://itnext.io/how-javascript-works-in-browser-and-node-a... and do you have an example of problematic code ?
The browser is the system. JavaScript is a language.
With such a definition of multithreaded language wouldn't Brainfuck also be one?
With such a definition of multithreaded language wouldn't Brainfuck also be one?
Read what I said again. Javascript is a language that will be executed using several threads when run in the browser environment.
However, that isn't the point. The point is that multiple Javascript scripts will be executing concurrently (via cooperative multitasking) and manipulating the same DOM elements.
This is absolutely a source of race conditions and a huge, HUGE pain in the ass for programmers who think Javascript is a 'single-threaded language'.
However, that isn't the point. The point is that multiple Javascript scripts will be executing concurrently (via cooperative multitasking) and manipulating the same DOM elements.
This is absolutely a source of race conditions and a huge, HUGE pain in the ass for programmers who think Javascript is a 'single-threaded language'.
Yep that's just as awful as JavaScript.
It seems author is making a point that modern C++ programming is degrading towards the same illness JS packages are: we're now going to be using libraries which are literally 60 lines of code in order to accomplish something that could be done by the standard library.
You might want to do something atomic with that clear.
Why is delvincasper posting projects from shalithasuranga's GitHub account? Easy upvotes?
This seems to spin up a thread for each `setTimeout`. The overhead of this is massive.
Sure, it's syntactically valid C++ (probably) but that's about it.