3 ms·
Neither are true. Non-blocking evented IO is mostly attractive from a usability point of view: it's much easier to write programs that aren't multi-threaded. I
by ender7 15y ago
Neither are true.
Non-blocking evented IO is mostly attractive from a usability point of view: it's much easier to write programs that aren't multi-threaded. It can also use much less memory than a threaded model in certain situations.
Non-blocking, evented systems tend to be single-threaded. Single-threaded systems don't automatically scale across multiple cores. To scale, you spawn a separate process for each core (for example, this is the suggested practice for node). You must then find some way for the different processes to communicate with each other, which is usually through a database (or some crazy pub-sub thing).
Node can scale just fine if you design your program to do so. It just scales in a different way.
- marshray 15y agoPersonally I love it, but some programmers find non-blocking evented "async" IO completely counter-intuitive. So it's debatable on the usability. Async IO is an absolute win from the scalability perspective because it allows you to service a great many clients with many fewer threads. OS thread context switches are relatively expensive. Ideally you would have exactly one OS thread per physical core and they would never need to block on exclusive access to any shared resources. Now that we have a system where the user code inside the async handler doesn't need to manage exclusive access to anything, from the usability perspective it can has some of the simplicity of code that is fully single-threaded. But that's subtly different from saying ASIO makes it easy. My guess is that many of the same programmers who aren't comfortable writing multithreaded code aren't going to find it completely intuitive to rethread their stack around an ASIO model.