This repository was archived by the owner on Nov 9, 2017. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 9, 2017. It is now read-only.
Discuss blocking on Zones proposal #166
Description
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.
Metadata
Metadata
Assignees
Labels
No labels
Activity
jasnell commentedon Aug 24, 2017
Count me in.
mcollina commentedon Aug 25, 2017
@bmeck can you link the original discussion? Which were the arguments that blocked it?
bmeck commentedon Aug 25, 2017
@mcollina most of the discussion is in domenic/zones#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 commentedon Aug 25, 2017
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 commentedon Aug 25, 2017
I would love to attend a meeting about it since I have a lot of experience with the problem
bmeck commentedon Aug 25, 2017
@Fishrock123 we have some flex on the API, but not on removing error handling as per domenic/zones#10 (comment)
jasnell commentedon Aug 25, 2017
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 commentedon Aug 25, 2017
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 commentedon Aug 26, 2017
@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 commentedon Aug 28, 2017
assigning in a meager attempt to not forget about this
Trott commentedon Sep 8, 2017
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.