timers: refactor setImmediate error handling #17879

apapirovski · 2017-12-27T16:36:07Z

If an error is encountered during the processing of Immediates, schedule the remaining queue to finish after all error handling code runs (if the process is still alive to do so). The new changes make the Immediates error handling behaviour entirely deterministic and predictable, as the full queue will be flushed on each Immediates cycle, regardless of whether an error is encountered or not.

Currently this processing is scheduled for nextTick which can yield unpredictable results as the nextTick might happen as early as close callbacks phase or as late as after the next event loop turns Immediates all fully process. The latter can result in two full cycles of Immediates processing during one event loop turn.

The current implementation also doesn't differentiate between Immediates scheduled for the current queue run or the next one, so Immediates that were scheduled for the next turn of the event loop, will process alongside the ones that were scheduled for the current turn.

It's possible this behaviour is semver-minor/semver-major although I would argue it's at worst semver-patch, as the current behaviour is entirely unpredictable and highly depends on what other operations are scheduled after the error handling is resolved.

CI: https://ci.nodejs.org/job/node-test-pull-request/12314/
CitGM: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/1174/

Checklist

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

Affected core subsystem(s)

src, timers, test

addaleax · 2017-12-27T16:44:27Z

src/env.h

+      kFieldsCount
+    };
+
+    uint32_t fields_[kFieldsCount];


From an initial look: It’s your call whether turning this into a class is helpful or not, but in any case the storage should only be accessed as an AliasedBuffer, since that is necessary for ChakraCore’s time-travel debugging to work with these values (because otherwise it can’t witness the changes from C++).

If you miss the availability of ++ and --, I guess it’s fair to add those to the AliasedBuffer reference class?

Thanks, wasn't aware of that. Will make some changes.

apapirovski · 2017-12-27T17:51:16Z

Ok, updated. PTAL @addaleax

CI: https://ci.nodejs.org/job/node-test-pull-request/12315/
CitGM: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/1175/
Benchmark CI: https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/80/

addaleax · 2017-12-27T17:59:08Z

lib/timers.js

-var immediateQueue = new ImmediateList();
+const immediateQueue = new ImmediateList();
+
+// If an error is encountered during execution of immediateQueue,


Optional: I would be specific and say “If an uncaught exception was thrown during execution …”

addaleax · 2017-12-27T18:00:06Z

lib/timers.js

    if (!immediate._onImmediate) {
      immediate = immediate._idleNext;
      continue;
    }

-    if (domain)
-      domain.enter();


Just making sure: These are a drive-by fix and not related to the exception handling itself, because domains use async hooks now anyway. Right?

I'm actually thinking that this should be a separate PR because this change could be back-ported but the domain portion probably can't.

addaleax · 2017-12-27T18:02:09Z

lib/timers.js

-const [activateImmediateCheck, scheduledImmediateCountArray] =
+// should match ImmediateInfo in src/env.h
+const kCount = 0;
+const kOutstanding = 1;


It’s not really obvious that this is a 0/1 flag, so I’d prefer to have it called something like kHasOutstanding?

addaleax · 2017-12-27T18:03:21Z

src/env-inl.h

+  return fields_[kCount];
+}
+
+inline uint32_t Environment::ImmediateInfo::outstanding() const {


This could return a boolean too, I guess?

If an error is encountered during the processing of Immediates, schedule the remaining queue to finish after all error handling code runs (if the process is still alive to do so). The new changes make the Immediates error handling behaviour entirely deterministic and predictable, as the full queue will be flushed on each Immediates cycle, regardless of whether an error is encountered or not. Currently this processing is scheduled for nextTick which can yield unpredictable results as the nextTick might happen as early as close callbacks phase or as late as after the next event loop turns Immediates all fully processed. The latter can result in two full cycles of Immediates processing during one even loop turn. The current implementation also doesn't differentiate between Immediates scheduled for the current queue run or the next one, so Immediates that were scheduled for the next turn of the event loop, will process alongside the ones that were scheduled for the current turn.

apapirovski · 2018-01-02T13:21:11Z

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

apapirovski · 2018-01-02T16:17:44Z

Landed in 54062d3

If an error is encountered during the processing of Immediates, schedule the remaining queue to finish after all error handling code runs (if the process is still alive to do so). The new changes make the Immediates error handling behaviour entirely deterministic and predictable, as the full queue will be flushed on each Immediates cycle, regardless of whether an error is encountered or not. Currently this processing is scheduled for nextTick which can yield unpredictable results as the nextTick might happen as early as close callbacks phase or as late as after the next event loop turns Immediates all fully processed. The latter can result in two full cycles of Immediates processing during one even loop turn. The current implementation also doesn't differentiate between Immediates scheduled for the current queue run or the next one, so Immediates that were scheduled for the next turn of the event loop, will process alongside the ones that were scheduled for the current turn. PR-URL: #17879 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]>

MylesBorins · 2018-01-09T23:43:52Z

This does not land cleanly on v9.x, could it be manually backported?

If an error is encountered during the processing of Immediates, schedule the remaining queue to finish after all error handling code runs (if the process is still alive to do so). The new changes make the Immediates error handling behaviour entirely deterministic and predictable, as the full queue will be flushed on each Immediates cycle, regardless of whether an error is encountered or not. Currently this processing is scheduled for nextTick which can yield unpredictable results as the nextTick might happen as early as close callbacks phase or as late as after the next event loop turns Immediates all fully processed. The latter can result in two full cycles of Immediates processing during one even loop turn. The current implementation also doesn't differentiate between Immediates scheduled for the current queue run or the next one, so Immediates that were scheduled for the next turn of the event loop, will process alongside the ones that were scheduled for the current turn. PR-URL: nodejs#17879 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]>

If an error is encountered during the processing of Immediates, schedule the remaining queue to finish after all error handling code runs (if the process is still alive to do so). The new changes make the Immediates error handling behaviour entirely deterministic and predictable, as the full queue will be flushed on each Immediates cycle, regardless of whether an error is encountered or not. Currently this processing is scheduled for nextTick which can yield unpredictable results as the nextTick might happen as early as close callbacks phase or as late as after the next event loop turns Immediates all fully processed. The latter can result in two full cycles of Immediates processing during one even loop turn. The current implementation also doesn't differentiate between Immediates scheduled for the current queue run or the next one, so Immediates that were scheduled for the next turn of the event loop, will process alongside the ones that were scheduled for the current turn. Backport-PR-URL: #19006 PR-URL: #17879 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]>

MylesBorins · 2018-07-31T18:38:14Z

Should this be backported to v8.x-staging? If yes please follow the guide and raise a backport PR, if not let me know or add the dont-land-on label.

apapirovski added c++ Issues and PRs that require attention from people who are familiar with C++. lib / src Issues and PRs related to general changes in the lib or src directory. timers Issues and PRs related to the timers subsystem / setImmediate, setInterval, setTimeout. labels Dec 27, 2017

nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. lib / src Issues and PRs related to general changes in the lib or src directory. labels Dec 27, 2017

addaleax requested changes Dec 27, 2017

View reviewed changes

apapirovski force-pushed the patch-timers-immediate-error branch from fe84d67 to 7e2c037 Compare December 27, 2017 17:49

addaleax approved these changes Dec 27, 2017

View reviewed changes

apapirovski force-pushed the patch-timers-immediate-error branch 2 times, most recently from 0c72b4f to 52d65d8 Compare December 27, 2017 19:05

apapirovski added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Dec 29, 2017

apapirovski force-pushed the patch-timers-immediate-error branch from 52d65d8 to 6d58100 Compare January 2, 2018 13:12

apapirovski force-pushed the patch-timers-immediate-error branch from 6d58100 to 3dd5c1b Compare January 2, 2018 13:19

jasnell approved these changes Jan 2, 2018

View reviewed changes

apapirovski closed this Jan 2, 2018

apapirovski deleted the patch-timers-immediate-error branch January 2, 2018 16:17

MylesBorins added the backported-to-v9.x label Jan 9, 2018

apapirovski added backport-requested-v9.x and removed backported-to-v9.x labels Jan 10, 2018

TimothyGu removed the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Jan 13, 2018

apapirovski mentioned this pull request Jan 31, 2018

[v9.x backport] 17738 and 17841 #18488

Closed

3 tasks

addaleax added backported-to-v9.x and removed backport-requested-v9.x labels Feb 26, 2018

addaleax mentioned this pull request Feb 27, 2018

v9.7.0 proposal #19040

Closed

MylesBorins added the backport-requested-v8.x label Jul 31, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

timers: refactor setImmediate error handling #17879

timers: refactor setImmediate error handling #17879

apapirovski commented Dec 27, 2017 •

edited

Loading

addaleax Dec 27, 2017

apapirovski Dec 27, 2017

apapirovski commented Dec 27, 2017

addaleax Dec 27, 2017

addaleax Dec 27, 2017

apapirovski Dec 27, 2017

apapirovski Dec 27, 2017

addaleax Dec 27, 2017

addaleax Dec 27, 2017

apapirovski commented Jan 2, 2018

apapirovski commented Jan 2, 2018

MylesBorins commented Jan 9, 2018

MylesBorins commented Jul 31, 2018

timers: refactor setImmediate error handling #17879

timers: refactor setImmediate error handling #17879

Conversation

apapirovski commented Dec 27, 2017 • edited Loading

Checklist

Affected core subsystem(s)

Choose a reason for hiding this comment

Choose a reason for hiding this comment

apapirovski commented Dec 27, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

apapirovski commented Jan 2, 2018

apapirovski commented Jan 2, 2018

MylesBorins commented Jan 9, 2018

MylesBorins commented Jul 31, 2018

apapirovski commented Dec 27, 2017 •

edited

Loading