Skip to content

Clarify when nextTickQueue is processed #1804

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.

Sign up for GitHub

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

Merged
1 commit merged into from
Feb 2, 2019
Merged

Clarify when nextTickQueue is processed #1804

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
57 changes: 55 additions & 2 deletions locale/en/docs/guides/event-loop-timers-and-nexttick.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -293,8 +293,11 @@ within an I/O cycle, independently of how many timers are present.
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
completes, regardless of the current phase of the event loop.
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
Expand Down Expand Up @@ -395,6 +398,56 @@ To get around this, the `'listening'` event is queued in a `nextTick()`
to allow the script to run to completion. This allows the user to set
any event handlers they want.

### Deduplication

For the `timers` and `check` phases, there is a single transition
between C to JavaScript for multiple immediates and timers. This deduplication
is a form of optimization, which may produce some unexpected side effects.
Take this code snippet as an example:

```js
// dedup.js
const foo = [1, 2];
const bar = ['a', 'b'];

foo.forEach(num => {
setImmediate(() => {
console.log('setImmediate', num);
bar.forEach(char => {
process.nextTick(() => {
console.log('process.nextTick', char);
});
});
});
});
```
```bash
$ node dedup.js
setImmediate 1
setImmediate 2
process.nextTick a
process.nextTick b
process.nextTick a
process.nextTick b
```
Copy link
Member

@ZYSzys ZYSzys Dec 20, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK, did the output incorrect ?
The output is always as below while my Node.js version is v11.4.0.

setImmediate 1
process.nextTick a
process.nextTick b
setImmediate 2
process.nextTick a
process.nextTick b

So it's indeed as @Trott said:

So in theory, the correct content of these guides is dependent on the version of Node.js...

Maybe we also need to explain this there.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right. Looks like something changed for node 11:

bash-3.2$ pbpaste
 const foo = [1, 2];
 const bar = ['a', 'b'];

 foo.forEach(num => {
   setImmediate(() => {
     console.log('setImmediate', num);
     bar.forEach(char => {
       process.nextTick(() => {
         console.log('process.nextTick', char);
       });
     });
   });
 });
bash-3.2$ nvm use 10.15.0
Now using node v10.15.0 (npm v6.4.1)
bash-3.2$ pbpaste | node
setImmediate 1
setImmediate 2
process.nextTick a
process.nextTick b
process.nextTick a
process.nextTick b
bash-3.2$ nvm use 11.0.0
Now using node v11.0.0 (npm v6.4.1)
bash-3.2$ pbpaste | node
setImmediate 1
process.nextTick a
process.nextTick b
setImmediate 2
process.nextTick a
process.nextTick b
bash-3.2$ nvm use 11.6.0
Now using node v11.6.0 (npm v6.5.0-next.0)
bash-3.2$ pbpaste | node
setImmediate 1
process.nextTick a
process.nextTick b
setImmediate 2
process.nextTick a
process.nextTick b

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like guides is not segregated by version. What would be the best way to indicate that this behavior is only applicable for Node 10 and below?

Also, what changed in node 11?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is what changed nodejs/node#22842


The main thread adds two `setImmediate()` events, which when processed
will add two `process.nextTick()` events. When the event loop reaches
the `check` phase, it sees that there are currently two events created by
`setImmediate()`. The first event is grabbed and processed, which prints
and adds two events to the `nextTickQueue`.

Because of deduplication, the event loop does not transition back to the
C/C++ layer to check if there are items in the `nextTickQueue` immediately. It
instead continues to process any remaining `setImmediate()` events, of which
one currently remains. After processing this event, two more events are
added to the `nextTickQueue` for a total of four events.

At this point, all previously added `setImmediate()` events have been processed.
The `nextTickQueue` is now checked, and events are processed in FIFO order. When
this `nextTickQueue` is emptied, the event loop considers all operations to have
been completed for the current phase and transitions to the next phase.

## `process.nextTick()` vs `setImmediate()`

We have two calls that are similar as far as users are concerned, but
Expand Down