On Fri, Sep 7, 2012 at 1:16 PM, Jimb Esser <[email protected]> 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! What I think you're saying is that the server will stop queuing messages AND execute the connection listener in the same synchronous tick. So there's no way a queued message will be delivered until after the connection listener runs. That makes sense. BTW, if I didn't understand that Node is single-threaded, I really shouldn't be attempting to teach a class on it. I do understand that part. ;-) -- 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
