lib: rearm pre-existing signal event registrations#24651
lib: rearm pre-existing signal event registrations#24651gireeshpunathil wants to merge 1 commit intonodejs:masterfrom
Conversation
|
@gireeshpunathil sadly an error occured when I tried to trigger a build :( |
77bbb0d to
58fc8ec
Compare
There was a problem hiding this comment.
Won't this always be true? It should always be at the very least an empty array.
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
minor nit: we can just do process.eventNames().forEach((ev) => {
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
|
|
||
| // re-arm pre-existing signal event registrations | ||
| // with this signal wrap capabilities. | ||
| process.eventNames().forEach((ev) => { |
There was a problem hiding this comment.
I thought we prefer for-of loops over forEach? (just a question)
There was a problem hiding this comment.
@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.
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.
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.
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 <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>
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>
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>
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>
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>
process.on('somesignal', ...) semantics expect the process to catch the signal and invoke the associated handler.
setupSignalHandlersperform 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