Just thought I would add from experience of building a threaded version of 
node. The process.* problem does not really exist if you create a new v8 
context for each thread, there are some issues, particularly with 
process.exit() behaviour but nothing too nasty. 

Modules are a 50:50 issue I think. If threads were supported in the core it 
would be fairly easy to provide helpers to handle thread specific data, I 
do that with a C++ template to most of the node globals, it's work but 
certainly not hard work unless you want to do something more involved that 
just maintain compatibility. On the other hand, I have just finished work 
on loading a threaded version of node as a native module into a stock 
version of node. This is really easy to deploy but I have not found anyway 
to make this support native modules, I kind of doubt there can be any 
single process solution given the current code, but I really like the model 
of being able to bolt fully functioning threads on as a module for those of 
us who care so I will probably look for other solutions.

I am really only chasing the gains to be had in shared state rather than 
any philosophical position, to that end I have tuned messaging passing 
between threads, a rough & ready benchmark shows throughput of 500k-msg/sec 
between threads, the comparative figure for inter-process is 20k-msg/sec, 
although this was only tested in WIN32. My work is on 
github<https://github.com/organizations/hut78>, 
but I am a couple of week away from an initial release, plenty of test 
cases to be run yet.


-- 
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

Reply via email to