Skip to content
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

Replacing four process.nextTick calls with four setImmediate calls. S… #806

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

deltaepsilon
Copy link

Response to #715

The process.nextTick deprecation warnings are causing problems on one of my servers. This appears to resolve those problems. Two tests were broken pre-commit, and those two tests are still broken, but no more have broken.

…hould get rid of the node warnings that are blowing up my call stack.
@kibertoad
Copy link
Contributor

What are the problems that this addresses?

@SgtPooki
Copy link

SgtPooki commented May 4, 2019

This pull request is 2 years old.

@kibertoad https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/ is the official explanation of whats going on, but some important bits are below:

You may have noticed that process.nextTick() was not displayed in the diagram, even though it's a part of the asynchronous API. This is because process.nextTick() is not technically part of the event loop. Instead, the nextTickQueue will be processed after the current operation is completed, regardless of the current phase of the event loop. Here, an operation is defined as a transition from the underlying C/C++ handler, and handling the JavaScript that needs to be executed.

Looking back at our diagram, any time you call process.nextTick() in a given phase, all callbacks passed to process.nextTick() will be resolved before the event loop continues. This can create some bad situations because it allows you to "starve" your I/O by making recursive process.nextTick() calls, which prevents the event loop from reaching the poll phase.

...
Why use process.nextTick()?
There are two main reasons:

Allow users to handle errors, cleanup any then unneeded resources, or perhaps try the request again before the event loop continues.

At times it's necessary to allow a callback to run after the call stack has unwound but before the event loop continues.

And in summary:

We recommend developers use setImmediate() in all cases because it's easier to reason about (and it leads to code that's compatible with a wider variety of environments, like browser JS.)

They give a few examples of why someone may want to explicitly use nextTick.. but ultimately you're breaking out of the event loop in an unexpected way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants