If you want to add something to core it'll need to be a GitHub issue. For all the same reasons non-blocking APIs fail on platforms that traditionally use threading a threading API in Node will fail just the same. It's a matter of community, the two approaches are not compatible and this means that the code in the community divides along these lines.
It's not good for the community to divide in to incompatible camps. Node code runs in node, period. If you want threads you'll need to fork, and you'll need to call it something other than node because it's not Node anymore, it's something else. Maybe it's better, but it's not Node. You can talk all day about the "possibilities" but your'e just talking about technology and waxing about what is possible. It doesn't really matter, it's not why things gain traction or grow a community, which is necessary for success. If you want to take on this science project, go for it, but take it off the list, this isn't productive. -Mikeal On Sep 17, 2012, at September 17, 20122:39 AM, Jorge <[email protected]> wrote: > On 17/09/2012, at 11:12, Ben Noordhuis wrote: >> On Mon, Sep 17, 2012 at 10:49 AM, Jorge <[email protected]> wrote: >>> On 17/09/2012, at 06:35, Ben Noordhuis wrote: >>> >>>> (...) >>>> That small gain is offset by the need to serialize access to your data >>>> structures - which is often a lot more expensive than the small gain >>>> you get by using threads. >>>> >>>> As for transferring objects, you don't need threads for that, just >>>> shared memory. >>> >>> If the processes are sharing memory, then they *too* "need to serialize >>> access to data structures"... >> >> Yes, but the big difference - and I hate to spell it out because it >> should be obvious - is that you only need to synchronize a single >> thing instead of every global data structure. > > > But that's a different problem. If you want to make thread-safe a program > that's abusing globals then yes you're ~ fucked. > > On the other hand it didn't take too long for the V8 guys to fix exactly that > in the isolates branch... > > >>>> We'll probably implement that someday but don't expect too much from >>>> it. Shared memory avoids some syscalls but the cost of moving the >>>> object from one V8 heap to another remains. >>> >>> That's the problem for transferable objects: there's no way to grab an >>> object reference from isolate A to use it on isolate B. >>> >>>> By the way, if you want to hasten that day, post (non-contrived) >>>> benchmarks that conclusively show that IPC is a bottleneck. :-) >>> >>> If the processes can communicate via shared memory -which is always a given >>> for threads- then IPC is fast. >>> >>> But if they can not then you've got to copy the data and speed becomes a >>> function of ( data.length ) which might be *irremediably* slow. >>> >>> Big data.length copies also flush other data from the caches, which results >>> in extra slowdowns. >>> >>> And as the memory bus is a shared resource, under high loads these (many) >>> unnecessary big.data.length copies will (pretty soon) have a global impact >>> on the performance of *all* the rest of system (รก la `cat /dev/zero > >>> /dev/null` memory bus bandwidth exhaustion). >> >> No doubt. Now show me the numbers. :-) > > Ok. Please tell me the secret :-P > > Because to me it's obvious that a copy of (sizeof void*) length is faster > than a copy of anything much larger than that. > > ? > -- > 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 [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 -- 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
