5 ms·
Timercpp: JavaScript-like setTimeout and setInterval for C++
- dsamarin 8y agoSeems 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.
- otabdeveloper1 8y ago> 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.
- ChrisSD 8y agoReally? I thought Javascript was single threaded, aside from webworkers?
- cannedslime 8y agoIt is...
- entelechy 8y agoyou don't need parallelism in order to create deadlocks or race conditions
- ChrisSD 8y agoI'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?
- TeMPOraL 8y agoThe 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: asynchronously doA(); blockReadingFile(); doB(); Whether doA() is finished or not when doB() executes depends on internals of doA() and on how long blockReadingFile() takes.
- kbumsik 8y agoIn 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#issuecomment-428104992 https://github.com/w3c/mediacapture-record/issues/150#issuec...
- sedeki 8y agoWhere did he mention ”parallelism”?
- otabdeveloper1 8y agoJavascript isn't single threaded. Callbacks happen asynchronously, and coupled with a synchronous DOM this means race condition central.
- jcelerier 8y ago> 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 while(true) { doPostedEvents(); } and executes your callbacks one after each other.
- otabdeveloper1 8y ago> 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.
- hawski 8y agoThe browser is the system. JavaScript is a language. With such a definition of multithreaded language wouldn't Brainfuck also be one?
- otabdeveloper1 8y agoRead 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'.
- 8y ago
- simfoo 8y agoThats basically what asio's timer do: https://www.boost.org/doc/libs/1_63_0/doc/html/boost_asio/example/cpp03/timers/time_t_timer.cpp 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.
- speps 8y agoWhy is delvincasper posting projects from shalithasuranga's GitHub account? Easy upvotes?
- AHTERIX5000 8y agoNot trying to be mean but why submit something like this to HN? This snippet just launches a thread per every timer using standard library and sleeps. There is no way to really stop anything or knowing if timers are active etc. Sure, it's syntactically valid C++ (probably) but that's about it.
- deleted 8y ago[deleted]
- ben0x539 8y agoI 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.
- csmattryder 8y agoIt'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?
- w-m 8y agoIt 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.
- BagOfPistchios 8y agoagreed, it is dangeorus if newbies try to use this
- pjmlp 8y agoIf it was only newbies doing such kind of errors. :\
- entelechy 8y agoThis setTimeout implementation has very different semantics compared to Javascript. The main issue is it creates a thread per invocation instead of using an eventloop.
- udp 8y agoExactly. 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.
- Tihiy 8y agoYep that's just as awful as JavaScript.
- adgasf 8y agoThis seems to spin up a thread for each `setTimeout`. The overhead of this is massive.
- heavenlyblue 8y agoIt 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.
- robmccoll 8y agoYou might want to do something atomic with that clear.