The short answer is that enough design decisions in Node's core are predicated on a single-threaded event loop that it would be prohibitively difficult to change. A large chunk of the module ecosystem builds on these decision in ways both obvious and subtle as well. Reasoning about async programming can be challenging; bringing race conditions and livelocks, which are hard to induce in individual Node processes right now, into the picture would be very, very painful.
Go made different decisions -- goroutines are an obvious nod to concurrency and parallelism, but channels are no less important a part of that story (look up "communicating sequential processes" if you want to learn more about the roots of that approach to concurrency). If you want something like that in node, using multiple processes with tools like the built-in cluster module give you most of the flexibility of goroutines, in not all the efficiency. On Saturday, March 22, 2014, cpprototypes <[email protected]> wrote: > The core of node.js is a single threaded event loop. Events get pushed > onto a queue and the event loop thread pops off events for processing. Is > it theoretically possible for the event loop itself to be multithreaded? > There's already a queue of things ready to be processed. What if there > were multiple threads processing the queue? I realize that for some > callbacks, the order of processing in the queue matters due to mutable > state. However, what if there was a way in JS or node.js to mark a > callback as "threadsafe"? Then the multi threaded event loop could just > look for those and run them without concern for order. > > I got this idea while studying how Go and goroutines work. They use > something like green threads which are tiny threads that get put on a queue > and processed. And Go can get easy parallelism by just increasing > GOMAXPROCS which basically just uses more "real" OS threads to process the > green threads. > > An event in node.js is not like a green thread, but they seem conceptually > similar. Could node.js have a kind of NODE_MAX_PROCS that would > multithread the event loop and process the event queue faster? > > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to > [email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');> > To unsubscribe from this group, send email to > [email protected]<javascript:_e(%7B%7D,'cvml','nodejs%[email protected]');> > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "nodejs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to > [email protected]<javascript:_e(%7B%7D,'cvml','nodejs%[email protected]');> > . > For more options, visit https://groups.google.com/d/optout. > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
