3 ms·
But coroutines _are_ an option for parallelism, and an especially effective one in the I/O-bound world. The parallelism comes from the OS handling I/O schedulin
by nurple 3y ago
But coroutines _are_ an option for parallelism, and an especially effective one in the I/O-bound world. The parallelism comes from the OS handling I/O scheduling for the coroutines instead of the application code.
The important difference between multithreading and multiprocess is that I can ignore synchronization that's not IPC in multiprocess models which makes the code much much simpler to implement and reason about.
I wouldn't even say this is web-centric, process-parallelism is a pretty common method of task dispatch in HPC compute topologies that has filtered down to smaller scales of multi-server compute clusters a la kubernetes. In these cases, taking a process-centric message-passing approach can greatly simplify not only the code but the architectural aspects of scheduling and scaling that are quite a bit more difficult with multi-threaded processes or even those that mix I/O and CPU-bound work in the same process (which is often a cause of thread starvation issue in node apps).
- spacechild1 3y ago> But coroutines _are_ an option for parallelism, and an especially effective one in the I/O-bound world. Parallelism means that code executes simultaneously (on different CPUs). Coroutines (on a single threaded executor) don't do that. > The parallelism comes from the OS handling I/O scheduling for the coroutines instead of the application code. Where exactly is the parallelism that is enabled by coroutines? Coroutines are nothing more than resumable functions. When it comes to I/O performance, threads vs. async is really a false dichotomy. What we should be comparing is 1. threads + blocking I/O 2. non-blocking I/O (select, poll, epoll) 3. asynchronous I/O (io_ring on Linux, IOCP on Windows) Coroutines may only provide syntactic sugar for 2. and 3.
- spacechild1 3y ago> The important difference between multithreading and multiprocess is that I can ignore synchronization that's not IPC Sure, if the data allows it and you can afford the memory and time overhead. There is no silver bullet! There are cases where you must work on in-process shared memory and process-parallelism wouldn't even be possible (think of multithreading in video games or DAWs). Note that if the data is properly partitioned, you might not need any locking, even with "normal" threads.