James M Snell

I'd be strongly -1 on trying to place limits on the number of `AsyncContext.Variable` instances created.

My initial instinct is option 1, `first iter` / `second iter`... specifically, the context whenever next() is invoked but I do see cases where option 2 would be useful also....

Thinking through this a bit... there are two contexts to be concerned about here. For `EventEmitter`/`EventTarget`: 1. The context that is current when the event is dispatched, e.g. `acval.run(2, ()...

It likely just needs to be recognized that in some cases, events are going to be triggered from the null-context ... that is, where no context is in scope when...

@jridgewell : > I think that if we make the null-context something that developers routinely encounter, then we've really failed on the ergonomics. What I imagine is that nearly everything...

The situation is really no different than once wrappers.

Our implementations of both EventEmitter and EventTarget already use wrappers. This really wouldn't be any different.

+1, this would definitely be useful. In Node.js we had to write some parsing logic for it also.

I'm not going to weigh in on any legal issue. What I would comment on is that there doesn't seem to be any real consideration in this conversation about what...

Ping on this... I would love to get this discussion moving again. I have my issues with how http/2 was designed but having http/2 in core would be good.