5 ms·
A watchdog thread can be running every n milliseconds. This is very low load on the system. [...] If the loop has not moved onwards since the last sample or t
by ot 15y ago
A watchdog thread can be running every n milliseconds. This is very low load on the system. [...] If the loop has not moved onwards since the last sample or two it can be deemed stalled. [...] But you can move the other events in the affected loop to a fresh thread; you can go sideways when you’ve detected a blocking task.
Congratulations, you just invented (a very inefficient version of) pre-emptive multitasking.
- willvarfar 15y ago(article author) Spot on except for the bit about being inefficient; presumed performance is very much the thing that makes the complexity worth it.
- deleted 15y ago[deleted]
- oconnore 15y ago> presumed performance is very much the thing that makes the complexity worth it. Presumed performance/complexity of what? That isn't even a comprehensible English sentence, never mind a well thought out rebuttal to the OP.
- bkirwi 15y agoIt seems clear to me that's he's talking about the performance / complexity of the algorithm that the article was about? There was significant discussion of the performance in the article, but the original commenter didn't have anything to contribute but a sassy comment. I'd be interested in hearing more about why he/she disagrees with the author's arguments, but frankly, a one-line criticism deserves a one line rebuttal. Also -- I'm not sure the comparison is accurate. Preemptive multitasking involves suspending the running process, while the author's suggestion involves emptying the queue behind the blocking process... or am I misunderstanding?
- oconnore 15y agoBut there are two algorithms in context here, and the more complex/efficient one is the OS preemptive scheduler. It then appears that 'willvarfar' is agreeing with 'ot' in a sentence that is structured as a critique. It confused me... > Also -- I'm not sure the comparison is accurate. Preemptive multitasking involves suspending the running process, while the author's suggestion involves emptying the queue behind the blocking process... or am I misunderstanding? I think the author's suggestion is to transparently spawn new threads when the event queue becomes blocked by a long running process. As soon as you do this, you lose a major advantage of the event loop in the first place -- namely that you don't have to worry about concurrency control because event handlers are atomic. I don't think (and it doesn't grep) he mentions anything about emptying the queue; why would that ever be a good idea?
- willvarfar 15y agospot on :)
- yxhuvud 15y agoWhat are your thoughts on the disruptor pattern? It seems to me to be something that tries to eat the cake of multithreading while still having a lot of the simplicity of eventing. ( https://code.google.com/p/disruptor/ https://code.google.com/p/disruptor/ )
- willvarfar 15y agoIts a very different approach. I do like their presentations and I've really got a thing for the "mechanical sympathy" term they coined. At a glance I'd say its not really the solving the same problems and isn't generally applicable to, say, application web servers. I would love to be educated on that score ;)
- jamii 15y agoThe disruptor is just a very efficient event loop. It doesn't prevent you from blocking the handling thread.
- yxhuvud 15y agoTrue, if you do blocking stuff in the handler instead of in the worker threads.