-
Notifications
You must be signed in to change notification settings - Fork 28.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
process: add deferTick #51471
process: add deferTick #51471
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
4bcb49e
to
7df14ac
Compare
bca84c2
to
e3ffd48
Compare
8520eff
to
2515178
Compare
Adds a new scheduling primitive to resolve zaldo when mixing traditional Node async programming with async/await and Promises. We cannot "fix" nextTick without breaking the whole ecosystem. nextTick usage should be discouraged and we should try to incrementally move to this new primitive. Refs: nodejs#51156 Refs: nodejs#51280 Refs: nodejs#51114 Refs: nodejs#51070 Refs: nodejs/undici#2497 PR-URL: nodejs#51471
No... I'm pretty sure this resolves it properly since it's not re-entrant. Can you provide an example?
I think you might be wrong. Again do you have an example)
What do you mean with promises api anyway? Example? |
Please don't get hung up on just solving the error handling case. We have the same problem with any other event. In those cases we have a deadlock instead of an uncaught error, which is even worse. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Adds a new scheduling primitive to resolve zaldo when mixing traditional Node async programming with async/await and Promises. We cannot "fix" nextTick without breaking the whole ecosystem. nextTick usage should be discouraged and we should try to incrementally move to this new primitive. Refs: nodejs#51156 Refs: nodejs#51280 Refs: nodejs#51114 Refs: nodejs#51070 Refs: nodejs/undici#2497 PR-URL: nodejs#51471
Adds a new scheduling primitive to resolve zaldo when mixing traditional Node async programming with async/await and Promises. We cannot "fix" nextTick without breaking the whole ecosystem. nextTick usage should be discouraged and we should try to incrementally move to this new primitive. Refs: nodejs#51156 Refs: nodejs#51280 Refs: nodejs#51114 Refs: nodejs#51070 Refs: nodejs/undici#2497 PR-URL: nodejs#51471
Adds a new scheduling primitive to resolve zaldo when mixing traditional Node async programming with async/await and Promises. We cannot "fix" nextTick without breaking the whole ecosystem. nextTick usage should be discouraged and we should try to incrementally move to this new primitive. Refs: nodejs#51156 Refs: nodejs#51280 Refs: nodejs#51114 Refs: nodejs#51070 Refs: nodejs/undici#2497 PR-URL: nodejs#51471
Adds a new scheduling primitive to resolve zaldo when mixing traditional Node async programming with async/await and Promises. We cannot "fix" nextTick without breaking the whole ecosystem. nextTick usage should be discouraged and we should try to incrementally move to this new primitive. Refs: nodejs#51156 Refs: nodejs#51280 Refs: nodejs#51114 Refs: nodejs#51070 Refs: nodejs/undici#2497 PR-URL: nodejs#51471
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
The
notable-change
Please suggest a text for the release notes if you'd like to include a more detailed summary, then proceed to update the PR description with the text or a link to the notable change suggested text comment. Otherwise, the commit will be placed in the Other Notable Changes section. |
I'm putting blocked label on this for now to make sure it doesn't land without more reviews. In particular I would appreciate feedback from @benjamingr and @jasnell |
I'm not sure what you mean by re-entrant in this context but basically: // Unhandled exception
setImmediate(async () => {
const e = await new Promise(resolve => {
const e = new EventEmitter()
resolve(e)
process.deferTick(() => {
e.emit('error', new Error('queueMicrotask'))
})
})
// also listen in a defer tick callback, presumably because of a library
process.deferTick(() => {
e.on('error', () => {})
});
}) Where the example is contrived (like the others) and in real-world usage the deferTick call would likely come from a library trying to "do the right thing" with a callback |
Just the fact you have to attach an error listener synchronously or you get an unhandled rejection - just like emitter errors |
@benjamingr I feel we are out of sync. Do you have any possibility for a 15 min call? |
Exactly, this is something that would be mostly used by library developers. We have already the problem with e.g. |
Due to war I'm less available but I'll come to the meeting in 3m but also you have my phone number and are always welcome to whatsapp me.
The question is what happens if the promise resolution is itself deferred by a deferTick in this case for example which would again prevent people from adding an error listener ahead of time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not thrilled with the idea of adding Yet Another Scheduling Primitive but not sure there's much of a choice if we want these cases to Just Work... so, LGTM
Adds a new scheduling primitive to resolve Zalgo when mixing traditional Node async programming (events and callbacks) with the micro task queue (i.e. async/await, Promise, queueMicrotask).
We cannot "fix" nextTick without breaking the whole ecosystem. nextTick usage should be discouraged and we should try to incrementally move to this new primitive.
queueMicrotask
is not sufficient to solve this as it is re-entrant.See following examples:
Refs: #51156
Refs: #51280
Refs: #51114
Refs: #51070
Refs: nodejs/undici#2497