| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
If think that IF we do this, which is something we need to very carefully consider given the very real chance of breakage, we should include an escape hatch in the form of a command-line argument that restores the original ordering. We can eventually deprecate that flag once the ecosystem has had a while to make the transition. ./node --legacy-microtask-ordering |
Sorry, something went wrong.
|
What about having it as an opt-in for now? |
Sorry, something went wrong.
|
It might be difficult or impossible to have this by default but I still think we need to have the possibility to opt-in as this is the only way to get "correct" behavior. |
Sorry, something went wrong.
There was a problem hiding this comment.
I would prefer if this super-hot function would not get a few more ifs. I think you could duplicate the implementation and only change the export.
This pattern would also allow us for more experimentation.
Sorry, something went wrong.
There was a problem hiding this comment.
lgtm
Sorry, something went wrong.
|
Please note that this is necessary as queueMicrotask is not sufficient to replace the current nextTick due to its re-entrance behavior. |
Sorry, something went wrong.
|
@mcollina I can't get this to work without a function wrapper due to the following lint rule: node:internal/options:20
({ options: optionsMap } = getCLIOptions());
^
Error: Should not query options before bootstrapping is done
at getCLIOptionsFromBinding (node:internal/options:20:32)
at getOptionValue (node:internal/options:45:19)
at setupTaskQueue (node:internal/process/task_queues:210:34)
at node:internal/bootstrap/node:306:38Any suggestions? Or who might have some idea? |
Sorry, something went wrong.
|
@joyeecheung You are the one that added the rule I believe? |
Sorry, something went wrong.
Sorry, something went wrong.
There was a problem hiding this comment.
is this actually faster?
Sorry, something went wrong.
This resolve multiple timing issues related to promises and nextTick. As well as resolving zaldo in promise only code, i.e. our current best practice of using process.nextTick will always apply and work. Refs: nodejs#51156 Refs: nodejs#51156 (comment) Refs: nodejs#51114 Refs: nodejs#51070 Refs: nodejs#51156 PR-URL: nodejs#51267
Sorry, something went wrong.
|
|
||
| > Stability: 1 - Experimental | ||
|
|
||
| Enable experimental task ordering. Always drain micro task queue |
There was a problem hiding this comment.
| Enable experimental task ordering. Always drain micro task queue | |
| Enable experimental task ordering. Always drain Microtasks queue |
It would also be useful to link to a doc like https://developer.mozilla.org/en-US/docs/Web/API/HTML_DOM_API/Microtask_guide#microtasks here.
Sorry, something went wrong.
| Enable experimental task ordering. Always drain micro task queue | ||
| before running `process.nextTick` to avoid unintuitive behavior | ||
| and unexpected logical deadlocks when mixing async callback and | ||
| event API's with `Promise`, `async`/`await`` and `queueMicroTask`. |
There was a problem hiding this comment.
Can you provide some examples? Without examples I doubt how many users would be able to recognize whether this can be useful for them and pick up this option.
Also note that we have a section in process.md saying..
every time the "next tick queue" is drained, the microtask queue
is drained immediately after.
I think that should be updated to mention this option.
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
This resolve multiple timing issues related to promises and nextTick. As well as resolving zaldo in promise only code, i.e. our current best practice of using process.nextTick will always apply and work.
Enable experimental task ordering. Always drain micro task queue before running process.nextTick to avoid unintuitive behavior and unexpected logical deadlocks when mixing async callback and event API's with Promise, async/await and queueMicroTask.
Refs: #51156
Refs: #51156
Refs: #51114 (comment)
Refs: #51070
Refs: #51156