3

As the title says, why does Node not support several event loops in one Process? The idea, is that node spawns a user decided number of threads, which each have an event loop. When a new callback is added, it is scheduled to one of the threads loops. The reason, probably against this idea is because now each thread can cause mutation and other bad stuff, but you could make the user decide what threads share state and so have to be run on the same thread or have a message like event memory sharing concept. This would help with computationally heavy tasks, this would reduce the overhead of sharing data between node instances to achieve the same result and therefore achieve better performance for the hardware and more user requests.

To make it more clear, when I mean several event loops, then that would be like forking and creating several node instances to utilise multiple cores but instead node itself would spawn 4 threads all with one event loop, so there is a lower cost of communication because it is using threads instead if instances if you are doing lot's of data sharing, not workers that you spawn to do heavy work and have nothing to do with the event loop.

Improve this question
1
  • 2
    Any time multiple threads all have access to the same data, the developer must protect ALL shared data with mutexes. This adds significant overhead, significant complexity and great difficultly to fully test, thus often leads to hidden bugs. Any design that avoids as much of that complexity is generally a good thing and that is node.js out of the box. It avoids that completely. If you want to use multiple threads or processes, you can do that yourself with something like the clustering module or by starting up child processes and then YOU coordinate access to whatever data must be shared. – jfriend00 Dec 28 '15 at 9:00
5

As soon as you have several threads running in the same process and sharing the same virtual address space, you got synchronization issues and you'll probably need to have mutexes (e.g. to deal with the case of several thread loops accessing the same object concurrently).

(I am assuming a Linux operating system with pthreads below)

So you'll need to extend the Javascript language for that; either you'll transparently add mutexes into every object making them heavier (a pthread_mutext_t has 40 bytes on my Linux/Debian/x86-64) and slower (you'll need to call something like pthread_mutex_lock on every access), or you put that burden on the user, forcing him to add additional code, and adding a new way of undefined behavior, and possibility of deadlock.

At last, multi-threaded garbage collection is quite difficult. Read the GC handbook for more.

BTW, on many Linux systems, processes are nearly as efficient and easy and fast to start as threads (see clone(2) used by pthreads and sometimes as substitute to fork(2)...), so having several dozens of Node.js processes makes sense. Also, local IPC (e.g. thru pipe(7)-s or unix(7)-s sockets) is very efficient on Linux, so the communication costs can be quite low (usually more than ten times faster than Ethernet on a local network).

Improve this answer
3
  • but you could make the user decide what threads share state and so have to be run on the same thread or have a message like event memory sharing concept, not causing synchronisation issues, however I can see that it would destroy nodes, no worry about it idiom of sharing state. – Coder3000 Dec 28 '15 at 8:38
  • and make it a lot harder for the node developers to implement it since js was never designed for multiple threads running at the same time. – Coder3000 Dec 28 '15 at 8:47
  • dozen's of node process may make sense, however the communication cost is still very high and more like a network request. – Coder3000 Dec 28 '15 at 8:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.