4 ms·

I understand the asynchronous part and the advantages associated with it, but what baffles me is that at the operating system level how do they work? If it has

I understand the asynchronous part and the advantages associated with it, but what baffles me is that at the operating system level how do they work? If it has to do something asynchronously should it not be mapped to OS threads and if so how do they have a performance advantage over things like Apache which make use of threads directly?

tlrobinson 16y ago
Two reasons usually given for async IO being more efficient than threaded servers are a) a large chunk of memory (on the order of a MB) must be allocated per thread (and thus per client) and b) the overhead of context switching. Both of these problems can be solved by things like green threads (which get scheduled on a single OS thread), coroutines, fibers, etc, though Node people will claim any sort of "machinery" like that will add unacceptable overhead. But aren't deeply nested callbacks and their associated closures also a form of "machinery", albeit one which must be explicitly managed by the programmer? The other argument against thread-like abstractions is the introduction of race conditions associated with shared memory. I believe coroutines sort of solve this, as do shared-nothing / message-passing systems like Erlang's "processes" and HTML5 Web Workers (and of course OS processes, though they're too heavyweight). [just realized the previous 2 paragraphs don't answer your question, sorry] Anyway, instead of blocking on a single socket operation per thread you can use select() and other more efficient APIs (poll, epoll, kqueue) to wake a single main thread when any of the sockets (out of hundreds or thousands) are ready for reading or writing. When there is no asynchronous API for some operation (like with many filesystem operations or existing database clients, for example) a thread pool is indeed used to make that operation asynchronous to the rest of the application (however depending on things like the disk cache, context switching might not be negligible, so Node now offers synchronous filesystem APIs as well)
- barfoomoo 16y ago
  Thanks. Did not know that async APIs at the OS level existed.

tlrobinson 16y ago

Two reasons usually given for async IO being more efficient than threaded servers are a) a large chunk of memory (on the order of a MB) must be allocated per thread (and thus per client) and b) the overhead of context switching. Both of these problems can be solved by things like green threads (which get scheduled on a single OS thread), coroutines, fibers, etc, though Node people will claim any sort of "machinery" like that will add unacceptable overhead. But aren't deeply nested callbacks and their associated closures also a form of "machinery", albeit one which must be explicitly managed by the programmer? The other argument against thread-like abstractions is the introduction of race conditions associated with shared memory. I believe coroutines sort of solve this, as do shared-nothing / message-passing systems like Erlang's "processes" and HTML5 Web Workers (and of course OS processes, though they're too heavyweight). [just realized the previous 2 paragraphs don't answer your question, sorry] Anyway, instead of blocking on a single socket operation per thread you can use select() and other more efficient APIs (poll, epoll, kqueue) to wake a single main thread when any of the sockets (out of hundreds or thousands) are ready for reading or writing. When there is no asynchronous API for some operation (like with many filesystem operations or existing database clients, for example) a thread pool is indeed used to make that operation asynchronous to the rest of the application (however depending on things like the disk cache, context switching might not be negligible, so Node now offers synchronous filesystem APIs as well)

barfoomoo 16y ago
Thanks. Did not know that async APIs at the OS level existed.