It was a very informative experiment, but has ultimately turned out to
cause too much instability in node's internal functionality to justify
continuing with it at this time. It requires a lot of complexity to
be added to libuv and node, and isn't likely to yield enough gains to
be worth the investment.
We're going to roll back the changes in master that were added to
support Isolates, and instead focus on Domains and other things that
promise to increase stability and make debugging easier. This change
will land in 0.7.3. It's entirely possible that we may decide to use
v8 isolates in some future version of node, but they will not be in
0.8.
If you were eagerly looking forward to using this feature, and find
yourself shocked or frustrated by this decision, please contact me
directly. It's not our intention to leave anyone stuck, and I do
understand that this feature was promised for some time. If this
causes hardship for you, let's figure out another way to get your use
cases handled.
It's never easy to back-pedal, but doing experimental things means
sometimes finding out that you were headed in the wrong direction.
The sooner we make this change, the easier it will be.
Thanks.
> --
> 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 nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
I think stability, debugging and modularity are good goals for 0.8.
---
Diogo R.
@Isaac I'm a little disappointed because this feature was going to make Node more able to do intense CPU-bound operations without blocking everything else, a limitation that is one of Node's biggest criticisms. The browsers elegantly solve this problem with web workers. Is there a reason Node couldn't use web workers or something like it to solve the issue?
You can do this today with child processes. Nothing about the
child_process module is being removed from the plans except the
{thread:true} argument, which requires a lot of internal changes to
support.
The drawback of using child processes instead of threads is that (a)
it's a bit more expensive to fire them up, and (b) all communication
has to be over a serialized channel (unless you use something like
shm_open).
Regarding (a), you still have the cost of starting the v8 context in
an isolate, so it's not *that* much of a savings. Regarding (b), web
workers serialize everything to json and back just like node's
child_process.fork() approach.
There are other semantic differences between processes and threads, of
course. They're very different from the system's point of view, and
so maintaining the same semantics with both approaches was part of
what made this feature so difficult.
Complaining out in the open is perfectly fine, too. But, I want
people to know that if this affects them, and they don't want to
publicize the inner workings of their technology, they're also welcome
to complain to me directly, and we'll make it right.
Kudos to you Isaac and the node dev community for putting a value on stability with prudent acts and transparent communication.
I recently decided to try node despite my sense that it might turn out to be just a little too hot and trendy. I chose to accept that risk. So decisions like this, communicated like this, make me feel very good about investing in node. Thank you!
Echoing Mark Hahn...
I'm not a slave to version numbers (not naming names, but we all know some 3.x FOSS with beta quality) but I am always wary of hype. And I have to say node lives up to its hype and the dev community has a refreshingly mature dedication for quality. Three cheers!
> it might turn out to be just a little too hot and trendyI know it isn't 1.0 but I've been using it in production for a year and loving it.
Retrofitting thread safety onto a code base that wasn't designed for
it leaves a very wide margin for obscure bugs. Offset against the
potential benefits (which were questionable and probably not
bottlenecks to most people*) the choice was not hard to make.
* Mostly faster worker start-up times and faster inter-worker communication.
For those of you who felt sad like I did when I read this :-/, and just in case you didn't notice yet the other thread "[nodejs] Evil threads [ANN] Threads a GoGo" ;-)
threads_a_gogo is out and ready for you to use: <http://github.com/xk/node-threads-a-gogo>
It lets you create -up to thousands of- JavaScript threads to run JS code in parallel with node's main thread, using all the available cpu cores, in v8 isolates, from within a single node process. It comes with the familiar API that you already know and love from node's asynchronous IO calls, in both event emitter (listeners) and continuation passing (callbacks) styles.
If you've downloaded the version 0.1.0 of threads_a_gogo already, please update now to the latest v0.1.1 that fixes a tiny (32 bytes) leak that was happening when a thread emits an event.
Cheers,
--
Jorge.
Please update now to the latest v0.1.2 that (now truly) fixes that tiny (32 bytes) leak.
--
Jorge.
I'm glad to hear you say that :-)
I'd love to hear what others' experiences have been.
In my unbiased :-P opinion it's much easier, the code is more readable, runs much faster, and requires less memory (less than 1/4th):
https://gist.github.com/2018811
https://github.com/xk/node-threads-a-gogo/
Cheers,
--
Jorge.
--
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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en