Live data from Hacker News

A Solution to CPU-intensive Tasks in IO Loops

williamedwardscoder.tumblr.com

11–20 of 26 posts

Re: A Solution to CPU-intensive Tasks in IO Loops

#11
post #10

The final question/answer is resolved around, Hellepoll has the concept of a task tree - tasks can be subtasks of others, and this simplifies tidy-up when one aborts. This explicit linking of tasks and callbacks can be used to determine what gets migrated when a task blocks, to ensure that the cascade of events associated with a request do not themselves get split, but fire in the originating thread and in the right…

Isolates have been removed.

http://groups.google.com/group/nodejs/browse_thread/thread/c...

Re: A Solution to CPU-intensive Tasks in IO Loops

#12
Check out lthread_compute_begin() and lthread_compute_end() functions. It allows you to block inside a coroutine without affecting other coroutines. (example at the end of the page)

I prefer coroutines over IO loops because they result in simpler and cleaner code. And with lthread_compute feature, you get the advantages of real threads + the lightness of coroutines.

https://github.com/halayli/lthread

Re: A Solution to CPU-intensive Tasks in IO Loops

#13
a lot of comments here, including the OP, simply miss the point. I work in the embedded world; I work on embedded electronics for the automotive sector. I write C and C++ code that is multi-threaded and I deal with things such as the CAN and LIN bus and watchdog timers. Just the mere comment that a watchdog "is very low load on the system" is a disturbing comment to me. It's a signal you think that the watchdog need not be very accurate and that you can slip a few milliseconds. Simply not true. When you miss your timing things stop working. Your hardware reboots itself if the watchdog isn't kicked on time, you wind up with bus errors on a vehicle network if you don't send the LIN break signal precisely on time or you're preempted when you've sent the break and now you're breaks are too long. When things like this happen, you effect other hardware. Most of these articles talking about threads, processes, and scheduling of such never seem to account for interfacing with external hardware. Many of it is simply wrong.

Re: A Solution to CPU-intensive Tasks in IO Loops

#14
post #2

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.

(article author) Spot on except for the bit about being inefficient; presumed performance is very much the thing that makes the complexity worth it.

> 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.

Re: A Solution to CPU-intensive Tasks in IO Loops

#15
post #6

So the server has multiple threads. If a handler blocks in one thread, another thread can pick up incoming requests. So far, so good. In return for needing to carefully synchronise access to shared state, we get to efficiently share that state (even if its just a hot cache of secure session cookies - things you don’t want to be validating every incoming request etc) between many threads and multiplex incoming request…

Do you have a link describing the "serializing tokens" concept?

I'm looking for other uses of this boost::asio concept of a 'strand'. http://www.boost.org/doc/libs/1_49_0_beta1/doc/html/boost_as... Specifically: a serialization constraint wrapping an arbitrary set of handlers.

Re: A Solution to CPU-intensive Tasks in IO Loops

#16

Earlier quoted context omitted.

(article author) Spot on except for the bit about being inefficient; presumed performance is very much the thing that makes the complexity worth it.

> 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.

It 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?

Re: A Solution to CPU-intensive Tasks in IO Loops

#17

Why don't you just lock each connection handler to one thread at a time and dispatch events on a thread pool ? That way connection level events are always synchronous, but event handlers are spread over the thread pool, you get optimal load balancing because events fill the pool (no processes) and thread pool can use it's own logic to grow if one channel handler used blocking IO and is blocking the a pool thread. Thi…

It does have advantages from code-organisation, but not from all-out performance.

One of the complexities of this is ensuring that a selector doesn't return a handle as being read/writable when another thread is still executing a previous trigger.

Re: A Solution to CPU-intensive Tasks in IO Loops

#18
post #6

So the server has multiple threads. If a handler blocks in one thread, another thread can pick up incoming requests. So far, so good. In return for needing to carefully synchronise access to shared state, we get to efficiently share that state (even if its just a hot cache of secure session cookies - things you don’t want to be validating every incoming request etc) between many threads and multiplex incoming request…

Tokens are very interesting.

A key thing I've learned on my travels is how critical shared state is to performance.

At its crudest, lots of web frameworks read a request, wait to receive it all, dispatch it to a handler, gather all the output from the handler, buffered, and then write it.

This is great from the code organization perspective.

Hellepoll is so very much faster because it streams the requests.

Without a green threading approach, this necessarily makes the code slightly uglier, and much more for the coder to juggle.

Of course there are at least three layers in an event loop framework:

* the programmer making the event loop itself who has to juggle everything;

* the prorgammer making the various protocol handlers who has to understand everything too but fits the framework conventions rather than creates them;

* finally the programmer who is using the framework who gets to use the utility and decoration and wrappings made by the protocol programmer and who hopefully doesn't have to understand in anything but the broadest terms the way the framework ticks.

I'm a big fan of Clojure and STM, but that's correctness over performance. I would hope whoever makes some other platform puts as much effort into hiding and protecting the inner shared state that is so critical to performance.

Re: A Solution to CPU-intensive Tasks in IO Loops

#19
post #2

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.

(article author) Spot on except for the bit about being inefficient; presumed performance is very much the thing that makes the complexity worth it.

What 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/ )

Re: A Solution to CPU-intensive Tasks in IO Loops

#20
post #19

Earlier quoted context omitted.

(article author) Spot on except for the bit about being inefficient; presumed performance is very much the thing that makes the complexity worth it.

What 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/ )

Its 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 ;)

Post reply on HN