This is following my earlier question Node.js Non Blocking Nature . I still can't feel I completely understand what is happening with Node.js . Lets say Node got a request for a big file upload from a user . Now we say we put the code to handle with the file in a callback , thus making it asynchronous . What happens next ? Lets say the callback got put in a big list of events the Node.js app needs to take care of , so thus far it is NOT blocking . But at some point the callback gets pulled out from the event loop and it's code starts running (uploading or downloading the file , whatever) . What now ? Is the Node.js app being blocked now ? If so - how does it not destroy the app's performance , and if not - who is in charge of 'jumping' between different events and requests ? We understand that in apache or similar servers there is special code to handle all the threads(timing them) so that no thread chokes all the others .In Node however , as I understand , there is an event loop . When the file I\O finishes , it's callback magically returns with the ready file . Nevertheless , the server still has to do the I\O , no escaping that ! Is the code in the event loop being timed ? For example jumping between different events(callbacks..whatever) so that no request chokes the other? If so , in what manner ?
All the I/O is handled internally by node.js using multiple threads; it's the programming interface to that I/O functionality that's single threaded, event-based, and asynchronous.
So the big upload of your example is performed by a separate thread that's managed by node.js, and when that thread completes its work, your callback is put onto the event queue (to be executed by the single JavaScript thread).
Think of the single JavaScript thread as pulling callbacks off the head of the queue and executing them serially until the queue is empty. Then it sleeps until one of the internal I/O threads puts a new callback on the queue.
This article discusses the related topic of process.nextTick which helped me understand some of these details.
Although node.js is often described as "non-blocking", what that really means is that it doesn't block on i/o. If it has to do something processor intensive, sure, other things have to wait. But if it is just waiting for data to be returned from the file system or the network, node will not block your process.
In the case of a slow file upload it is processing, periodically it is going to have to do something, as data comes in (possibly calling your callback, but possibly just storing that data until it has enough to call your callback). But computers are fast, and whatever happens is, for all intents and purposes, instantaneous. It's the fact that network operations are relatively slow that we are concerned about. In a language like Php, typically, your function will not return until this operation is complete, and there is nothing else you can do in that script, until that happens. Meanwhile, the CPU could be sitting idle...simply waiting for data to come in across the network. Node, on the other hand, let's you use the CPU for other things, before your callback is called.
As others have noted, there may be threads happening under the hood. Or there may not be, since node could internally implement file and network operations using non-blocking C++ functions. Doesn't matter. The important thing is that i/o operations do not block other things from happening within your app.
I think this subject is complicated enough (at least for newcomers) to deserve a thorough read and can't be understood by read a 5 line answer. This is the best resource I found http://www.theserverside.com/discussions/thread.tss?thread_id=61693 . He doesn't think so highly of Node.js but he does take a lot of effort to explain it . Worth a read in my opinion.