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

lib: rearm pre-existing signal event registrations #24651

Closed
wants to merge 1 commit into from

Conversation

gireeshpunathil
Copy link
Member

process.on('somesignal', ...) semantics expect the process to catch the signal and invoke the associated handler. setupSignalHandlers perform the additional task of preparing the libuv signal handler and associate it with the event handler. It is possible that by the time this is setup there could be pre-existing registrations that pre-date this setup in the boot sequence.

So rearm pre-existing signal event registrations to get those upto speed.

This is required by node-report; however given its independent existence
raising is a separate one.

I wish I could add a test for this, but realize it might not be possible, as the logic is exercised within the boot sequence that is not influenced / intercepted by any test cases.

Ref: #22712 (comment)

/cc @addaleax

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines

@nodejs-github-bot
Copy link
Collaborator

@gireeshpunathil sadly an error occured when I tried to trigger a build :(

@nodejs-github-bot nodejs-github-bot added the process Issues and PRs related to the process subsystem. label Nov 26, 2018
@gireeshpunathil gireeshpunathil added the lib / src Issues and PRs related to general changes in the lib or src directory. label Nov 26, 2018
// re-arm pre-existing signal event registrations
// with this signal wrap capabilities.
const events = process.eventNames();
if (events != null) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Won't this always be true? It should always be at the very least an empty array.

Copy link
Member Author

Choose a reason for hiding this comment

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

@mscdex - thanks, yes - the process object was subjected for events in the previous block, so there should be a non-null array. I removed the check now and tested, all good. PTAL.

// re-arm pre-existing signal event registrations
// with this signal wrap capabilities.
const events = process.eventNames();
events.forEach((ev) => {
Copy link
Contributor

Choose a reason for hiding this comment

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

minor nit: we can just do process.eventNames().forEach((ev) => {

Copy link
Member Author

Choose a reason for hiding this comment

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

@mscdex - done, and squashed. thanks.

process.on('somesignal', ...) semantics expect the process to catch the
signal and invoke the associated handler. `setupSignalHandlers` perform
the additional task of preparing the libuv signal handler and associate
it with the event handler. It is possible that by the time this is
setup there could be pre-existing registrations that pre-date this setup
in the boot sequence.

So rearm pre-existing signal event registrations to get upto speed.

Ref: nodejs#22712 (comment)
Copy link
Member

@mhdawson mhdawson left a comment

Choose a reason for hiding this comment

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

LGTM


// re-arm pre-existing signal event registrations
// with this signal wrap capabilities.
process.eventNames().forEach((ev) => {
Copy link
Member

Choose a reason for hiding this comment

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

I thought we prefer for-of loops over forEach? (just a question)

Copy link
Member Author

Choose a reason for hiding this comment

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

@joyeecheung - thanks, I am unaware of any such preferences; pls let me know (or any links on) if there are any merits / tradeoffs between the two?

Copy link
Member

Choose a reason for hiding this comment

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

Just an observation, at least I thought we prefer for-of loops...
(on a side note, I took a look at the bytecode generated with for-of loops and they look humongous compared to forEach loops)

Copy link
Member

Choose a reason for hiding this comment

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

from perf standpoint, forEach is usually faster in newer versions of V8. from from a semantic standpoint i think it looks better to use forEach, but that's just opinion.

Copy link
Member Author

Choose a reason for hiding this comment

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

thanks @joyeecheung @devsnek for the reasoning; so I am keeping things as is.

@gireeshpunathil
Copy link
Member Author

@Trott Trott added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Nov 28, 2018
@gireeshpunathil
Copy link
Member Author

@Trott
Copy link
Member

Trott commented Nov 28, 2018

Landed in 25ad8de

@Trott Trott closed this Nov 28, 2018
Trott pushed a commit to Trott/io.js that referenced this pull request Nov 28, 2018
process.on('somesignal', ...) semantics expect the process to catch the
signal and invoke the associated handler. `setupSignalHandlers` perform
the additional task of preparing the libuv signal handler and associate
it with the event handler. It is possible that by the time this is
setup there could be pre-existing registrations that pre-date this setup
in the boot sequence.

So rearm pre-existing signal event registrations to get upto speed.

Ref: nodejs#22712 (comment)

PR-URL: nodejs#24651
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
targos pushed a commit that referenced this pull request Nov 29, 2018
process.on('somesignal', ...) semantics expect the process to catch the
signal and invoke the associated handler. `setupSignalHandlers` perform
the additional task of preparing the libuv signal handler and associate
it with the event handler. It is possible that by the time this is
setup there could be pre-existing registrations that pre-date this setup
in the boot sequence.

So rearm pre-existing signal event registrations to get upto speed.

Ref: #22712 (comment)

PR-URL: #24651
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
@BridgeAR BridgeAR mentioned this pull request Dec 5, 2018
4 tasks
refack pushed a commit to refack/node that referenced this pull request Jan 14, 2019
process.on('somesignal', ...) semantics expect the process to catch the
signal and invoke the associated handler. `setupSignalHandlers` perform
the additional task of preparing the libuv signal handler and associate
it with the event handler. It is possible that by the time this is
setup there could be pre-existing registrations that pre-date this setup
in the boot sequence.

So rearm pre-existing signal event registrations to get upto speed.

Ref: nodejs#22712 (comment)

PR-URL: nodejs#24651
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
BethGriggs pushed a commit that referenced this pull request Feb 12, 2019
process.on('somesignal', ...) semantics expect the process to catch the
signal and invoke the associated handler. `setupSignalHandlers` perform
the additional task of preparing the libuv signal handler and associate
it with the event handler. It is possible that by the time this is
setup there could be pre-existing registrations that pre-date this setup
in the boot sequence.

So rearm pre-existing signal event registrations to get upto speed.

Ref: #22712 (comment)

PR-URL: #24651
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
@BethGriggs BethGriggs mentioned this pull request Feb 12, 2019
rvagg pushed a commit that referenced this pull request Feb 28, 2019
process.on('somesignal', ...) semantics expect the process to catch the
signal and invoke the associated handler. `setupSignalHandlers` perform
the additional task of preparing the libuv signal handler and associate
it with the event handler. It is possible that by the time this is
setup there could be pre-existing registrations that pre-date this setup
in the boot sequence.

So rearm pre-existing signal event registrations to get upto speed.

Ref: #22712 (comment)

PR-URL: #24651
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. lib / src Issues and PRs related to general changes in the lib or src directory. process Issues and PRs related to the process subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants