remove #2629 signal handler from interchange #3588
Labels
Comments
|
Your reasoning sounds right to me. |
benclifford
added a commit
that referenced
this issue
Oct 14, 2024
This was introduced in PR #2629 to guard against the submit process installing a SIGTERM handler and then that handler being unexpectedly inherited by the interchange via multiprocesssing fork PR #3463 changed the interchange to run as a fresh Python process, which will not inherit SIGTERM handlers, so since then this line has been vestigial. Fixes issue #3588
benclifford
added a commit
that referenced
this issue
Oct 14, 2024
This was introduced in PR #2629 to guard against the submit process installing a SIGTERM handler and then that handler being unexpectedly inherited by the interchange via multiprocesssing fork PR #3463 changed the interchange to run as a fresh Python process, which will not inherit SIGTERM handlers, so since then this line has been vestigial. Fixes issue #3588
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
PR #2629 added a force of signal handler because it needs to deal with being launched by multiprocessing.fork. PR #3463 makes interchange into its own process, which should get default signal handlers anyway (?) and so I think there's no need for this additional complication.
cc @rjmello who has looked at interchange start/exit the most recently
The text was updated successfully, but these errors were encountered: