Instead of forking (crude-cloning) processes into splitted (distinct) context for each child process,
we instead employ workers (CPU heavy computations e.g. for DNS lookup) within single-threaded-context (thread pool) . I see workers (a.k.a. threads) as some sort of virtualization (optimization) within same boundaries of memory (RAM) at time . This image helped me a lot to comprehend what I stated in my comment above ; I'll be honest I may be mistaken , always welcome to give alternative argument for that .
That's a nice article! Although, just to re-iterate, I was talking about the threadpool which libuv maintains.
A very brief explaination :
As I mentioned, at its core, node expects the OS to do the heavylifting. And different Operating Systems have different mechanism of doing that, hence node folks built an abstraction library called libuv. This library abstracts event loop and the OS interactions(fun fact, you can use this lib stand alone).
Now, let's say there's an operation which node wants to do differently, or there's something which OS can't handle or doesn't support. To manage such scenarios libuv has its own threadpool, and this threadpool(default size 4) simulates the async behavior which node expects from OS.
Instead of forking (crude-cloning) processes into splitted (distinct) context for each child process,
we instead employ workers (CPU heavy computations e.g. for DNS lookup) within single-threaded-context (thread pool) . I see workers (a.k.a. threads) as some sort of virtualization (optimization) within same boundaries of memory (RAM) at time . This image helped me a lot to comprehend what I stated in my comment above ; I'll be honest I may be mistaken , always welcome to give alternative argument for that .
That's a nice article! Although, just to re-iterate, I was talking about the threadpool which libuv maintains.
A very brief explaination :
As I mentioned, at its core, node expects the OS to do the heavylifting. And different Operating Systems have different mechanism of doing that, hence node folks built an abstraction library called
libuv. This library abstracts event loop and the OS interactions(fun fact, you can use this lib stand alone).Now, let's say there's an operation which node wants to do differently, or there's something which OS can't handle or doesn't support. To manage such scenarios libuv has its own threadpool, and this threadpool(default size 4) simulates the async behavior which node expects from OS.