SIGQUIT handler being ignored when node is loaded as a shared library

[sxa]

• Version: 4 and later
• Platform: Most UNIX-based platforms, but reported on xLinux
• Subsystem: core - signal handling

I've had a report from a user that is having an issue with #615 which set all signal handlers back to the default ones. The user is loading a shared library build of node, and it is overriding their own SIGQUIT signal handler (actually one set by the JVM their application uses but that's not inherently relevant) so the expected behaviour of their application is being altered when they load the node.js runtime dynamically.

While the reasons for removing any existing handlers (when node is being exec'd from another process) may have been sound, I suspect it is likely to be generally undesirable in the shared library case where we are being invoked by another application.

I'm open to thoughts on this so am raising this issue while mulling solutions:

1. I could look at not resetting any existing handlers in the shared library case (the most obvious option!)
2. We could just leave any SIGQUIT handler in place to resolve this particular scenario
3. We could look at skipping more of the startup section when loaded as a shared library
4. Have a runtime parameter to control the overrides
5. Something else?

FYI @bnoordhuis @sam-github since you wrote/reviewed the original PR, and @stefanmb for info ;-)

[sam-github]

My 2 farthings: 1 and 3 looks reasonable, 2 seems excessively specific (SIGHUP or INT for example could quite reasonably have handlers set by the host process), 4 sounds excessively flexible for this specific problem (though maybe there is a set of problems that could all be helped with such a mechanism).

[gibfahn]

So presumably 1. is a subsection of 3. , i.e. if we're skipping the handler reset we should also look at skipping some other not-shared-library-suitable stuff? If so that seems like something we should be doing/checking in general.