On Wednesday, November 14, 2012 at 12:11 PM, pie_lard wrote: > On Wednesday, 14 November 2012 19:46:28 UTC, Forrest L Norvell wrote: > > If you're willing to make liberal use of domain.bind(), there's no reason > > why you can't just have one domain for a whole class of requests and add > > long-lived connections to the domain directly (although then it becomes > > more important to analyze the lifecycle of the domains and ensure that > > you're disposing of them properly when they're no longer needed). > > > That wouldn't work in the case of pooled connections (or any pooled resources > that outlive requests) because you'd just have to add the connection to the > domain as soon as you require it (and remove it when you've finished). In > which case you'd be better off if domains simply could be installed and then > 'followed' every callback from that point onwards. No need for your code to > ensure it hasn't switched domains. I think I mentioned this already upthread, but the solution is to add support for domains to the modules that handle connection pools (here's my first stab at this, for node-redis: https://github.com/mranney/node_redis/pull/310). When the drivers are connection-aware, they work more or less exactly as you describe. When the API is more mature, app developers shouldn't have to even know about the implementation details of domains to use them.
> > It's worth mentioning that domains are simple objects and are pretty cheap > > to create -- mostly just the cost of creating a new EventEmitter and adding > > a couple closures to it. Unless your code is super-hot, it shouldn't add > > very much overhead to run a specific request in a domain. > Yes - I'm not questioning the performance of domains at all. In that case, it's not really a big deal to run each request in its own domain, is it? > > > Maybe this would only work if node were to maintain a stack of domains - > > > I'm not sure of the implications of that. > > > > > > > > > > Domains can be nested -- only the current innermost domain will receive > > error events. This is handled by a stack internally to the domain code. You > > could get multiple listeners on a domain by adding additional listeners, > > although you'd have to clean them up at the end of the scope manually. > > Probably better just to create a new domain. > > > Yes - I saw that in the docs. I suppose what I'm asking amounts to: would it > matter if domains simply didn't keep track of EventEmitters - what would be > the implications? I think that might make nesting simpler (and could possibly > happen automatically whereas it doesn't at the moment to prevent resource > leaks). The problem is that without wrapping up EventEmitters, the domains will get lost due to how async calling chains work. If you set the domain to be "global", you can never have overlapping domains, or in other words you lose request-specific context. Domains are basically trying to recreate synchronous call stacks by wrapping context around the asynchronous call graph, and to do that they need to wrap all of the various ways that Node sets up asynchronous execution (that's what the bulk of the domain-specific code does, in fact). > > > I realise I'm probably missing something important here ;) Either what > > > I'm suggesting wouldn't work or couldn't be easily implemented. I see > > > there's another discussion going on on this list about node modules that > > > seem to be alternatives to domains (or are they built on domains > > > somehow?), > > > > > > > I'm aware of very few third-party modules taking advantage of domains so > > far. If anybody else knows of any, it would be awesome to hear about it. > > > > > I assume that any external library built on top of uncaughtExceptions won't > be able to track all callbacks without wrapping a lot of the standard library > functions or something like that. I mean, domains are the best solution > because they are built into node and can thus do things that an external > module can't (easily anyway). You can do it, but it's hard and the results have performance implications. Look at longjohn or trycatch (which Adam Crabtree was just discussing on another thread). They use closures and shims that wrap around the same things that domains support from inside the Node core library. Domains have the potential to be a much simpler, cheaper solution to the more general problem of tying errors and requests together. 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
