This repository has been archived by the owner. It is now read-only.

Domain binding on defining event listeners #3646

wants to merge 4 commits into


None yet
4 participants

skidding commented Jul 5, 2012

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)


bnoordhuis commented Jul 5, 2012


@isaacs You should review this.

isaacs commented Jul 6, 2012

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()
ee1.on('foo', handle)
ee2.on('foo', handle)

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.

skidding commented Jul 6, 2012

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."


isaacs commented Jul 17, 2012

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.


luk- commented Feb 26, 2013

Looks like this went stale, is it still up for discussion?

@isaacs isaacs closed this Feb 26, 2013

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.