search

nodejs / CTC

Node.js Core Technical Committee & Collaborators
80 stars 27 forks source link

Discuss blocking on Zones proposal #166

Closed bmeck closed 6 years ago

bmeck commented 7 years ago

https://github.com/domenic/zones is a proposal that is currently being blocked by Node.

The proposal is something similar to domains and async_hooks in creating a way to pass data through asynchronous tasks.

The blocker has been the handling of errors with the proposal.

I would like to setup a meeting to discuss the blocking behavior now that async_hooks is landed.

jasnell commented 7 years ago

Count me in.

mcollina commented 7 years ago

@bmeck can you link the original discussion? Which were the arguments that blocked it?

bmeck commented 7 years ago

@mcollina most of the discussion is in https://github.com/domenic/zones/issues/9 . That was the addition of error handling.

Most of the concerns were with the similarity w/ domains and the problems from those. See the domain post-mortem and polyfill using domains.

Over the last year opinions of supporting async workflows w/ error handling like Promises and tooling around swallowed errors has been improved greatly. I think we should re-iterate on the discussion from scratch.

Fishrock123 commented 7 years ago

I guess I can join - can we experiment with something that achieves the goal of zones without necessarily using it's current proposed API?

I mean with the API may be fine to but only if VMs can entirely optimize the -every API call passes through it- overhead away.

benjamingr commented 7 years ago

I would love to attend a meeting about it since I have a lot of experience with the problem

bmeck commented 7 years ago

@Fishrock123 we have some flex on the API, but not on removing error handling as per https://github.com/domenic/zones/issues/10#issuecomment-324754750

jasnell commented 7 years ago

can we experiment with something that achieves the goal of zones without necessarily using it's current proposed API?

Let's not use this thread to begin litigating on the specifics of the proposal, that's not going to be a good use of our time now. Setting up a call to begin that process is the right thing.

benjamingr commented 7 years ago

I've just reread it. @trevnorris has shown in the domains postmortem why they broke (of "mine" "their" "mine" with the middle not cleaning). He then showed with @bmeck why it doesn't work with Zones like it didn't with domains.

It's amazing that Node can block this - and we did the right call doing so. It's a shame because without the error handling it was very nice for many other things as well.

bmeck commented 7 years ago

@benjamingr I agree (hence my previous involvement), but a meeting can make a discrete list of what Node is blocking for error handling would be good. There is a consistent desire for "thread" context, but we can't move it forward without the error handling use case. A meeting on what is different about error handling now that tooling has evolved and what async_hooks allows seems prudent since this proposal is potentially being withdrawn if we don't move anywhere on it.

Fishrock123 commented 7 years ago

assigning in a meager attempt to not forget about this

Trott commented 6 years ago

I'm going to close this, but feel free to open another issue in a relevant active repository (TSC perhaps?) and include a link back to this issue if this is a subject that should receive continued attention. Recent governance changes mean this repo probably shouldn't be used anymore. Sorry for the inconvenience.