fs: do not emit 'stop' watch event synchronously

[claudiorodriguez]

Checklist

• make -j4 test (UNIX), or vcbuild test nosign (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

Affected core subsystem(s)

Description of change

Emits 'stop' event for fs.watchFile on process.nextTick
to fix 'maximum call stack size exceeded' error when
stop is called synchronously after listener is attached.

Fixes: #8421

[cjihrig]

LGTM pending CI.

[mscdex]

CI: https://ci.nodejs.org/job/node-test-pull-request/4038/

[imyller]

@claudiorodriguez Just wondering if setImmediate instead of nextTick should be used here?

https://github.com/nodejs/node/blob/master/doc/topics/the-event-loop-timers-and-nexttick.md#processnexttick-vs-setimmediate states that:

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.)

setImmediate is bit more asynchronous since it fires on the following iteration or 'tick' of the event loop; meaning that stop event would be emitted there.

I noted that nextTick is the preferred solution in core lib/. Maybe for a good reason.

[claudiorodriguez]

@imyller just tried that change locally, it passes all tests successfully. I'd be inclined to make the change, it makes sense, although maybe someone from @nodejs/collaborators can chime in, if process.nextTick is preferred for a particular reason.

[bnoordhuis]

process.nextTick() is lower latency, it's dispatched as quickly as possible. setImmediate() postpones the callback until the next loop tick.

(process.nextTick() was an apt name when it was introduced but not anymore.)

[yorkie]

@claudiorodriguez 2 suggestions from me:

• the test file should be renamed to test-fs-watch-stop-sync.js.
• we should also add a test file test-fs-watch-stop-async.js to make sure that the trigger calls emit() in next ticks.

[jasnell]

While I'm good with this change in general, I'm wondering if this needs to be semver-major due to the change in timing? I don't believe it does but want to be careful

[claudiorodriguez]

@yorkie good idea, I'll do that this weekend

@jasnell I'm trying to think of a way in which userland code listening to the emitter would break, but can't think of any - seeing as how the contract remains the same. Can you think of any user code that would behave differently?

[claudiorodriguez]

@yorkie added the test, PTAL

New CI: https://ci.nodejs.org/job/node-test-pull-request/4123/
(although CI seems to have been failing for a while)

[mcollina]

Can we avoid allocating a new closure here? When calling stop() on a massive tree of objects, we will be allocating a lot of closures for nothing.

this._handle.onstop = function() {
  process.nextTick(emitStop, self)
}

// to be put a root level
function emitStop(self) {
  self.emit('stop');
}

[claudiorodriguez]

@mcollina changed, PTAL

[imyller]

LGTM

[jasnell]

@claudiorodriguez ... no, I can't think of anything either. As I said, this should be perfectly fine.

[jasnell]

LGTM

[jasnell]

New CI: https://ci.nodejs.org/job/node-test-pull-request/4222/

[yorkie]

LGTM :)

[imyller]

Landing:

• Five LGTMs
• No objections
• CI test passed (only the known CI failures)

/ping @jasnell you were thinking about adding semver-major label for this. Still relevant?

[imyller]

landed in 1b97774

[imyller]

To be safe, I've added dont-land- labels until semver level is discussed and resolved.

[addaleax]

Hm, bump? Does anybody feel this should be semver-major? If not, I’d like to remove the labels.

[Fishrock123]

Changes event timing, sounds major to me