Handle SIGTERM in a similar manner as SIGINT (^C) when starting jpype with interrupt=False

[dfangl]

Proposal

We are currently using jpype to integrate some java libraries with our project. However, it is vital for us to regain control in python on SIGTERM as well as on SIGINT.

SIGINT handling is currently implemented when the appropriate flag is set (interrupt=False), however this does not work for SIGTERM, and for compatibility reasons, we would prefer both signals to be handed over.

This would improve the usage of jpype in long running, non-interactive processes which need proper shutdown logic, especially if it is hard to use the shutdown hooks for this logic, in our case because it contains a webserver, which requires to be shut down from the main thread.

Changes necessary

We needed to move fast with our usage of jpype, so we forked jpype already and applied a patch which leads to SIGTERM being handled the same as SIGINT: master...localstack:jpype:master#diff-49bead28f65cc4854943ff252ab201f7b866795548315fd0c21cfb24d6c672f0

I would be happy to file a PR, should this change be accepted.

[Thrameos]

I have no issue with improvements for sigterm. But doesn't the JVM use some of those signals for garbage collection. IIRC it even issues one when starting up. Though I may have a wrong signal.

Assuming this is optional behavior and doesn't break the JVM, please submit a PR.

[dfangl]

Would you prefer having the SIGTERM behavior behind the same or a separate flag as the SIGINT one (which uses interrupt)?
I will file a PR for the current approach (using the same flag), we can discuss it in the PR as well.

As far as I have observed, there are no ill effects on the JVM, the jvm should not signal any SIGTERM against itself.

[Thrameos]

Best a separate flag as the interrupt flag was mostly for interactive vs non-interactive would be my guess. Though perhaps @marscher has a different opinion.

I am likely thinking of sigfault being used by gc. Will need to check the sources.