There are long discussions in the Node community about what happened when we did try to use Isolates. The lack of thread level protections from things like mucking with process.* and the fact that native modules need to add complex support for Isolates to be first class (many C level libraries deal poorly with Isolates due to them not being exactly like threads from what I understand) are fairly well discussed. In addition things like C's abort(), and any shared memory still cause problems with Isolates. It would be interesting to delve into these problems, but for example if you use rust the runtime has explicit knowledge of threads rather than v8 so you can reduce most of the problems with concurrency to message passing and the same problems as process.* . People who complain about threads generally do not have in depth knowledge of difficulties in doing so with Node's environment, but should feel free to look them up and discuss solutions rather than simply stating "it should have threads". I personally really like what Threads a Go Go does, but it still faces the difficulties listed above difficulties when you start to delve deep into it.
On Sunday, September 16, 2012 4:51:43 PM UTC-5, rektide wrote: > > TL;DR: > > 1. Threads are a feature, one that will unlock new exciting things we can > do and make > existing features better (namely child_process.fork()). > 2. "We don't have that feature" is not a feature, is not a pro. > 3. Being dogmatic about what others ought do is bad: accept if not embrace > input liberally. > 4. Doing threads, safe concurrency right is what makes Rust so attractive, > and Node can do > it safely, cleanly too and nearly did, in the "isolates" branch. > https://github.com/joyent/node/tree/isolates > > Onwards: > > On Sat, Sep 15, 2012 at 11:32:56AM -0700, Mark Hahn wrote: > > @rektide, are you saying that joyent is asleep at the wheel because > they > > are stopping the community from using threads?� > > The community doesn't want threads because they violate the founding > > principle of Node, which is to use non-blocking event loops and get > rid of > > threads. > > "violate the founding principle"? > "community doesn't want"? > > As for "doesn't want" and "founding principles," before threads became an > awful horrible > thing the Node community would have nothing to do with ever, there was a > feature that got > canned for being too complicating called Isolates, that, shock and awe, > Node leads were hard > at work on which would have added threading as a drop in replacement for > child_process.fork(). > Certainly no one was calling the feature "anti-Node" at the time, it would > have been an > implementation detail, offered the same functionality as already exists in > Node today, and > would have made us capable of doing more. > > https://groups.google.com/forum/?fromgroups=#!msg/nodejs/zLzuo292hX0/F7gqfUiKi2sJ > > https://github.com/joyent/node/tree/isolates > > Threading is not evil. Shared state is evil. Which is why the rest of the > JavaScript world > has Transferables, a way to move ownership of an object from one isolated > thread/container > to another. Processes preservation [read: apropo exclamative], Node is > already a > multi-reactor not a reactor, and there's no harm, nothing but technical > gain (faster context > switches, Transferables), from allowing that multi-reactor to run on > threads as easily as it > runs on processes. Aside from the work to get there, there's no cause to > keep ourselves > locked in to just using processes. > > http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#transfer-a-transferable-object > > > I'm not at all saying Joyent is asleep at the wheel. They punted on this > topic, this big > hard hairy to implement topic: fine. It does hurt us, is a killer feature > a mature runtime > ought have in it's toolkit, but I have faith eventually we'll go to bat on > the topic again > in a serious manner in due time and I'm not sweating the innings lost > between now and then. > In the mean time, Joyent has been doing great things with Node and I'm > delighted they > continue doing so much to further Node. > > > > I know Ryah has gone on twitter and said he still sees Node as a web > runtime. Isaac has > similarly lamented allowing other languages to play in Node's pool. > Online discussions have > a lot of people defending node's lack of threading. I think much of this > makes us look bad, > (hipster-ish, dogmatic, and even jingoistic), to soapbox about what this > thing is for, to > rather than find value and positives define negatives and ills, to > proscribe. > > For comparison, I'd champion Larry Wall's Perl: a super flexible language, > but what I love > more than anything else is how a-dogmatic it was, an explicitly > post-modern language with > an explicitly post-modern culture, where people didn't tell each other > what to think or do > and couldn't do otherwise in any kind of definitive manner because there > were a dozen ways > to do a thing: liberty came standard. Even if you were using it to shoot > yourself in the > foot, the guy on the other side of the lab can be using feature X or > factor Y to great > effect. > > Make options available, help people see what things are possible. That's > humble, that's > respectful, and speaks to an understanding that lasting things grow and > change and take on > new roles. If we knew all the answers, we'd have built ourselves > all-too-sterile and > flavorless an environment. > > Threads are great. Fact. Better than processes (at at least context > switching and > transfering objects). Fact. And like most great powers, they come with > great responsibility > (more than processes, fact). Which isolates, WebMessaging all support, all > work to harness > the capabilities of while insuring they are used responsibly. > > > > Fwiw, Rust is going to be a serious language to look at because it has > such deeply ingrained > respect for safe concurrent containers. And continuing my opining, Node > owes itself > isolates, it's parallel: threads are faster context switches than > processes, and threads allow > Transferable, both are clear safe wins with zero risk or cost to > non-users. Threading is a > feature, one from a usage standpoint that need not be any different than > child_process.fork(), and it's one I hope Node.js comes back to to > continue being a > pre-eminent and delighting runtime for all users. > > Happy hacking all, > -r > > > > This thread was forked from the Crockford fork YNode thread below, > https://groups.google.com/d/msg/nodejs/QsygwyrXi5U/e9enAhGiVlQJ > > > On Sat, Sep 15, 2012 at 11:19 AM, Ted Young <[1] > t...@radicaldesigns.org <javascript:>> > > wrote: > > > > I take it no one knows what he's actually complaining about? > > Ted > > I've got some idea what Nuno is groaning about. :) Threads-a-go-go is a > pretty daft silly thing. > It's certainly not the safe sane shared-nothing threading that keeps Node > & JS safe. That > responsible multi-threading work was attempted in the 'isolates' branch of > Node.js. I would > definitely not push the threads-a-go-go work upstream. :) > > > On Sep 15, 2012, at 10:52 AM, Nuno Job > > <[2]nunojo...@gmail.com<javascript:>> > > > wrote: > > > > This again? Oh mah gawd. :) > > > > Sent from my iPhone > > > > On Sep 15, 2012, at 6:18 PM, rektide > > <[3]rek...@voodoowarez.com<javascript:>> > > > wrote: > > > > On Sat, Sep 15, 2012 at 04:56:40PM +0200, Arnout Kazemier > wrote: > > > > "Pull request or it didn't happen" > > > > Hi: > > > > [4]https://github.com/xk/node-threads-a-gogo , or preferrably > some > > better isolated manner of > > multi-threading with Transferable objects. > > Sorry for not linking some Isolates earlier, which is the unspoken answer > to "better > isolated" above. > -- 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 nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
