-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
Conversation
@gireeshpunathil sadly an error occured when I tried to trigger a build :( |
77bbb0d
to
58fc8ec
Compare
// re-arm pre-existing signal event registrations | ||
// with this signal wrap capabilities. | ||
const events = process.eventNames(); | ||
if (events != null) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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) => { |
There was a problem hiding this comment.
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) => {
There was a problem hiding this comment.
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)
2679a8a
to
5f0cbdb
Compare
There was a problem hiding this 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) => { |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Landed in 25ad8de |
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 <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: Joyee Cheung <[email protected]>
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 <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: Joyee Cheung <[email protected]>
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 <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: Joyee Cheung <[email protected]>
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 <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: Joyee Cheung <[email protected]>
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 <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: Joyee Cheung <[email protected]>
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), orvcbuild test
(Windows) passes