An off-the-shelf node can't execute *JavaScript* code in parallel (*), because *only* *one* of its *multiple* threads runs a (single) v8 JS VM.
But a node with the threads-a-gogo module can create as many (up to thousands) additional V8 JS VMs as needed, and execute javascript code truly in parallel, in additional threads: <https://github.com/xk/node-threads-a-gogo> (*) But in every node process there's always a bunch of threads running... so node's *not* single threaded. -- Jorge. On 07/09/2012, at 20:16, Jimb Esser wrote: > It sounds like you might be misunderstanding something fundamental about > node/Javascript - it's all single threaded, and (at least the networking > stuff) is event-based (specifically a stream of sequential events, since > there's no concurrency). In your example, while it's running line 5, there's > no way it's going to miss anything because that's the only code that is > running, nothing could possibly be pumping the event loop. Until your > function returns from handling the event, node is not going to handle the > next event coming from the socket. Even if the data has been sent and > buffered in the kernel for your server process, it's not going to fire any > events until node tries to read from it/pumps the event loop. Lots of node > APIs rely on this kind of behavior (e.g. HTTP request/response stuff > similarly lets you set up event listeners in a connection event before it > could possibly fire any data events). Hope this helps! > > Jimb Esser > > On Friday, September 7, 2012 10:35:28 AM UTC-7, Mark Volkmann wrote: > On Fri, Sep 7, 2012 at 12:01 PM, mscdex <[email protected]> wrote: > On Sep 7, 10:21 am, Mark Volkmann <[email protected]> wrote: > > On Fri, Sep 7, 2012 at 9:09 AM, Ben Noordhuis <[email protected]> wrote: > > > > The client queues write requests until the connection handshake is > > > > > done. Said handshake is complete when the server accepts the > > > connection, which node does right before it calls your connListener > > > function. > > > > If that is true then why is the first message from the client lost if I do > > this? > > Probably because the accept and incoming data happen within the same > tick. This is why you should add a data handler right away, or at > least pause() the socket right away. > > Sounds reasonable. I'm currently teaching a class on Node.js. I'd like to say > something better to the students than "This code probably works because ...". > That's why I'm trying to either find a place where this is documented or find > where the queuing of messages and releasing of them actually happens in the > code. > > -- > R. Mark Volkmann > Object Computing, Inc. > > -- > 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
