Premise: Domains work best only in a synchronous flow. To cover async situations, though, timers bind current domain to their callbacks and event emitters store it in their constructor. (maybe other stuff as well...)
Problem: Async callbacks returned from low-level libraries, like in the case of net streams, are not covered. If the event emitter was not defined inside a certain domain, nor will listeners added to it get bound to any present domain.
Solution: Binding domains on adding event listeners and activating them on emit. (similar to how intervals handle domains)
Attached current domain to event listeners on add
Added handler domain on event emitting
Added handler domain on event emitting w/ multiple handlers
Added simple test for event listeners defined inside domains
@isaacs You should review this.
This is a pretty significant semantics change. Also, if I'm reading this right, you're going to get into trouble if you do things like:
d1 = domain.create()
d2 = domain.create()
Since the relevant domain becomes the one on the function rather than the EventEmitter, it's going to be confusing: I've added an EE to a given domain, but something else was active when the ee.on() was called, and now the ee's domain is not the one it's bound to all the time.
The idea is that a domain "owns" the emitter object itself. If a single EE object is switching domains for different handlers, then that's strange. Also, a single event handler could be applied at different times to different emitters (this is quite common, in fact), and you'll get really odd crosstalk, since the last one to attach it to any event is the one that's going to catch errors it throws.
How about if we inverted the order of loading the domains? That is, if the event emitter has already been added to a domain then that one will be activated, otherwise, fallback on the one present when the listener was defined (if any).
This way it won't change any present behavior, but instead cover more domain "holes."
Can you explain the "hole" (ie, the use case that you expect to be covered, which isn't already) in a message to the nodejs-dev list?
I'm not against it in principle, but it should be discussed, since it's a change in semantics. Let's first get some agreement about the problem and the expected behavior.
Looks like this went stale, is it still up for discussion?