On Fri, Aug 30, 2013 at 10:07 AM, Alvaro Mouriño <[email protected]> wrote:
> I failed to see how could domains be implemented in > userland, at least with an unpatched version of Node, and it seems > that it's just not possible. It's completely possible to do the kind of error handling that domains does in userland, and in fact Adam Crabtree has dealt with the same problem domains are meant to solve with trycatch ( https://github.com/CrabDude/trycatch), which is in some ways a conceptually cleaner approach to error handling. If you look at how continuation-local-storage-glue is implemented, they have similar implementations, which is to wrap all of the functions that can lead to asynchronous execution (process.nextTick, setImmediate, setTimeout, I/O that touches ReqWrap / MakeCallback in the C++ side of Node) so that you have an opportunity to do whatever you need with the callback to be executed asynchronously. > My question now is, wouldn't it be better > to have a standard (as in "inside of node") way of doing this? There > are some modules that I think would make sense to have in node, like > this one or logging. > One of the complaints about domains in Node 0.8 is that they reduced performance of everybody's code, regardless of whether they were using domains or not. Trevor Norris did a lot of work to mitigate this in 0.10, but it's led to some pretty exotic and weird code, which means added complexity in the Node code base. Not everybody wants to handle errors the same way, not everybody needs a concept as general and powerful (and esoteric) as continuation-local storage, and nobody wants logging to work the exact same between applications. However, we all want these things to be fast, which is what the work that Trevor's trying to land in 0.12 is meant to provide. The API he's working on (https://gist.github.com/trevnorris/6372405) makes it nearly trivial to build domains, trycatch, CLS, AOP-style loggers, long stacktrace modules, and a host of other functions that need to be able to work across async boundaries. It's much more in keeping with the Node philosophy to have one simple, general API in core and keep the rest in userland. To be clear: domains aren't going anywhere. But having them disentangled from the rest of Node core (in 0.8 and 0.10, domains code is everywhere) is a big win for keeping the core code small and simple. continuation-local-storage-glue works in 0.10 and 0.8 (and could probably be made to work with 0.6 without too much work, but c'mon), and the performance hit is noticeable but not tremendous. It will be considerably cheaper once something like Trevor's addAsyncListener lands. > Anyway. I think that we both try to achieve the same but have > different requirements. The restrictions that you mention led you to > write CLS don't apply to Kolba, I think. Maybe I'm missing something? > If you're writing applications and have a clear understanding of when you're using domains for error-handling and when you're using them for state propagation, you're fine. I'm writing an agent that runs inside applications, and those applications need to run the same whether or not my code is included. I have to be very careful about not altering existing error-handling behavior, and I need to be able to pass my state around without worrying about how developers are solving their own control flow, error-handling, or logging problems. Ultimately, all I can say is that domains were designed for error handling, and they do that pretty well. Everything else people use them for is just a byproduct. CLS is meant to do exactly what you want. 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.
