On Fri, Aug 30, 2013 at 9:25 AM, Dan Peddle <[email protected]> wrote:
> Could you explain a bit more about what you mean by continuation local > Sure. When you're handling a request in e.g. Express, the technique of wrapping up future computation in a callback and handing that to a function to be called when the function is done and computation is ready to proceed is known as continuation-passing style (CPS). The callback and its closure are the continuations in CPS -- they represent a context encapsulating future computation. CLS is meant to allow you to transparently set and get values that are specific to the execution of a specific chain of function invocations, or continuation evaluations. To cut the fancy CS talk, that means that you can have a whole bunch of requests in flight concurrently, all with their own state, and this is all done transparently to user code, across asynchronous call boundaries. It's exactly what you're doing with domains today, only decoupled from error handling. when the domain based technique failed..? > See my response to Alvaro for some of the context, but it helps to know that I'm writing an agent that traces the asynchronous execution of programs I didn't write, and in general know nothing about. The agent also is trying to capture information about as many errors that occur inside the program as possible, so it can gather and display information about them back to the developer. Further add onto that the possibility that the program in which the agent is running may itself be using domains. So you're going to have nested domains there, almost as a certainty -- for error gathering, for state propagation, and whatever the users of the agent are doing with domains themselves. If one of the enclosing domains is attached to, say, an event emitter, and it gets and handles an error, it's going to exit all of the domains it encloses (because domains are essentially asynchronous try/catch, and throwing in try/catch is a form of nonlocal exit or computed goto, domains have a stack which allows them to unwind state in an analogous way), which will completely nuke the ability to continue execution tracing, even if the error, for whatever reason, is treated as recoverable. That can be dealt with (through yet more monkeypatching of domains and / or event emitters), but the underlying conflation of concerns (error handling and state propagation) remains. In my case, having execution tracing and error handling decoupled is very close to a necessity, because the agent runs very close to Node core and also needs to work with multiple versions of Node, with their very different implementations of things like domains and process.nextTick. Edge cases are pretty much my entire world. > I understand that calling domain.exit() closed all current domains, for > example..? > Domain.prototype.exit() exits the current domains and all domains above it on the domain stack, which in effect means any domains that were entered after the domain currently being exited. Final one - while we're talking about it - under the hood, how do domains > work..? Reading the code, it seems to be hijacking execution contexts..? > A complete breakdown of how domains work in Node 0.10 is probably beyond the scope of an email message, but there are two main components of domains: 1. A small piece of C++ that captures any JavaScript exceptions that bubble up to the V8 toplevel and then hands them off to a function exposed globally on the JavaScript side of node (process._fatalException()). 2. A bunch of small bits of code scattered throughout the JavaScript source of Node that ensure that asynchronous things (timers, I/O listeners) are given the context necessary for the exception handler to find the correct function to invoke when there's an error. Sometimes this means wrapping closures around callbacks, sometimes this means attaching domains to EventEmitters or timers. It's all pretty pragmatic, except for the pieces that were added to make domains fast (which are a whole other story). F -- -- 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.
