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

Signal handling improvements #329

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

rhansen
Copy link

@rhansen rhansen commented Dec 21, 2020

Multiple commits (intentionally separate, please do not squash):

  • Signal handling: Factor out common signal handling code
  • Signal handling: Always exit non-zero
  • Signal handling: Allow worker.terminate() to be synchronous
  • Signal handling: Wait for all workers to terminate
  • Signal handling: Don't exit if there are other signal listeners

This is intended as an alternative to pull request #324.

@andywer
Copy link
Owner

andywer commented Dec 22, 2020

Great stuff, @rhansen! Thanks so much.

@mjgp2 Can you check if this fix solves the issue for you, too? I don't see any reason why not, but an additional test would still be nice.

@JeremieDoctrine
Copy link

JeremieDoctrine commented Sep 21, 2021

Hi, @andywer any reason not to merge this? This fixes our issue as well.

We've temporarily addressed this by doing :

    process.removeAllListeners('SIGTERM');
    process.on('SIGTERM', () => {
      ...
    }

But it is not really satisfying.

@Huararanga
Copy link

I dont think you should install any signal listeners it's dangerous and out of scope of the common library..

@rhansen
Copy link
Author

rhansen commented Oct 15, 2021

I dont think you should install any signal listeners it's dangerous and out of scope of the common library..

Note that this PR doesn't add signal handling, it only attempts to improve the existing signal handling. Removing the signal handlers entirely is a topic that deserves discussion in a dedicated bug report. The scope of this PR is intentionally narrow to avoid breaking existing users.

@CMCDragonkai
Copy link

Can signal handling be provided by as an additional utility function that users can install? It's quite dangerous for the signal handlers to be installed upon import.

@rhansen
Copy link
Author

rhansen commented Dec 1, 2021

Can signal handling be provided by as an additional utility function that users can install? It's quite dangerous for the signal handlers to be installed upon import.

I'm all for that, but it would require a major version bump. This PR attempts to preserve compatibility as much as possible so that it can be merged without delay (ping @andywer). My preference would be to merge this as-is, then open another PR that overhauls cleanup.

Note that Node.js currently does not provide a robust way to perform cleanup actions, so there may never be a completely satisfactory solution. See nodejs/node#29480.

rhansen added 5 commits April 16, 2022 01:48
The default signal handler always exits non-zero so the signal
listener installed by threads.js should too.
This also suppresses any synchronous exceptions thrown by
`worker.terminate()`.
The promise returned from `Promise.all()` immediately rejects if any
of the underlying promises reject, even if some of the other promises
have not yet settled. Catch each rejection to give the other promises
an opportunity to resolve.

`Promise.allSettled()` could be used instead, but that's a relatively
new function that was added in Node.js v12.9.0.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants