1. this has 2 parts. first part, when you call an async function, the control is given back to the event loop. somewhere, at the end of the current stack there is registry, managed by the loop. in this registry is maintained which function, or better function object, is associate with which event should be called. second, in your code, you create the callback functions for db calls. this are the functions, that are directly, or as values in scope of other functions, are registered by the loop. When the event appears, the associated function is called. second part: the functions preserve usually their state via closure scope or this binding. when you create a callback, which you pass to the db call, you create a new function object on every request, that holds all the state with it, such as references to the response object. so when this callback function is called, it retains all its state from the moment when your request handler completed.
2. for file i/o libuv uses a thread pool under the hood. for network i/o there are bindings to the native evented network lib. user land native bindings are different, but most will do the same as node: either using libuv or utilize a thread pool (or use some other async lib) Am Donnerstag, 8. August 2013 11:59:41 UTC+2 schrieb Brian Lalor: > > On Aug 8, 2013, at 1:03 AM, aman saggar <[email protected] <javascript:>> > wrote: > > > 1. 1)*How is the state is being maintained here?* > > > a. If this is single threaded model, then the with the second > request coming, it wouldn’t have idea of the initial request or state > > i. If > it actually dumps the information to memory and then works on, and once it > receives event , loads state from memory > > > > > I. Then how it is different from multi-threading, which > forking and joining. > > > You're passing a function into http.createServer(); that function is > invoked for every request and has its own scope. Each time that function > is called it gets its own stack (local variables, etc.). Arguments passed > into the function are local variables. The variables aren't shared between > invocations of the function; there's no shared state and JavaScript's > single-threaded model means your code is never interrupted, so you don't > need to worry about managing concurrent access to those (or any other) > variables. > > As for "who is running those non-blocking items?": the operating system. > OS primitives like select() and epoll() (?) are used by Node to determine > when data is available to be read or written to a file descriptor. (All IO > can basically be generalized to file descriptor operations.) IO is the > only non-blocking operation in JavaScript, unless you're explicitly putting > a callback onto the event loop with setTimeout or setImmediate. > > -- > Brian Lalor > [email protected] <javascript:> > http://github.com/blalor > > -- -- 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 --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
