-
Notifications
You must be signed in to change notification settings - Fork 27
Discuss blocking on Zones proposal #166
Comments
Count me in. |
@bmeck can you link the original discussion? Which were the arguments that blocked it? |
@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. |
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. |
I would love to attend a meeting about it since I have a lot of experience with the problem |
@Fishrock123 we have some flex on the API, but not on removing error handling as per domenic/zones#10 (comment) |
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. |
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. |
@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. |
assigning in a meager attempt to not forget about this |
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. |
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.
The text was updated successfully, but these errors were encountered: