Bug ID: JDK-8257572 Deprecate the archaic signal-chaining interfaces: sigset and signal

Type: Enhancement
Component: hotspot
Sub-Component: runtime
Affected Version: 16

Priority: P3
Status: Resolved
Resolution: Fixed

Submitted: 2020-12-02
Updated: 2020-12-17
Resolved: 2020-12-07

JDK 16
16 b28Fixed

The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction:

https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html

Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages:

sigset:  This API is obsolete: new applications should use the POSIX signal API  (sigaction(2), sigprocmask(2), etc.)

signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux.  Avoid its use: use sigaction(2) instead.

We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17.

It is difficult to foresee where code like this is used. The using coding does not have to be aware of the existence of the JVM or libjsig at all. Any code running alongside the JVM in the same process which calls signal() or sigset() is affected. I am not even sure what to tell customers how to prepare. "If you use libjsig, look into all your native code which potentially runs alongside the JVM, as well as all native libraries used via JNI, if any of that code uses sigset(2) or signal(2)". sigset() or signal() may still work, even in a multithreaded program. And the funny thing is, even if it did not, the fact that it had been used with our libjsig may have made it work :) because we translated their signal() call into, effectively, a sigaction call by chaining it to our signal handler. So the more I think about this, the less sure I am that this deprecation is worthwhile. I would at least postpone it until post JDK17, to not affect the next LTS.
11-12-2020
Thanks for the input [~smarks] - I confess I have been thinking about this with the VM's view on deprecation/obsoletion/expiration. But yes this is terminal deprecation and yes it is "horribly broken". We also expect that people migrated away from these obsolete APIs many years ago. I should point out that anyone using the signal interposition library that desperately needed signal/sigset to keep "working" (eg. because they don't have the source for an existing binary launcher) could easily write their own signal interposition library that just defines sigset/signal in terms of sigaction, where the sigaction call would in turn be intercepted by libjsig. They would then just add their library to the LD_PRELOAD path (already needed by libjsig). To clarify the scope of impact here, this change requires the following conditions to be met: - A custom launcher process that directly loads the JVM - The custom launcher needs to install signal handlers after the VM is loaded (there is no issue with installing before by any mechanism as libjsig is not involved) - The custom launcher uses the archaic signal/sigset functions to install their handler so it is expected to be a tiny fraction of a tiny fraction of a tiny fraction of JDK application developers. I did a google search on using libjsig to see what turned up. I found old reference to the JOGL (OpenGL binding) effort but that was for Java 6. I found one issue with IBM J9 implementation of signal chaining where the test program used signal rather than sigaction. I also found the LibreOffice use of signals but they already use sigaction as expected: https://gerrit.libreoffice.org/c/core/+/38916/3/sal/osl/unx/signal.cxx [~stuefe] Do you have any further insights/thoughts on this? Thanks.
10-12-2020
From reading the description, warning message, and release notes, it's clear that this is a "terminal deprecation" (deprecation with intent to remove in the future) as opposed to ordinary deprecation (which essentially means "avoid using this" and nothing more). The typical policy has been to leave APIs in a terminally deprecated state for a year in order to allow time for migration. However, it's for this to be shorter in certain cases, for example, if something is so horribly broken that nothing can reasonably be depending on it, or if it's getting in the way of adding something important. Given that `signal` and `sigset` are undefined for multithreaded processes, and the JVM is inherently multithreaded, it seems like this falls into the "horribly broken" category. Still, it might be worthwhile to do some investigation to see if anyone might be depending on the deprecated interfaces.
09-12-2020
Changeset: 149a02f9 Author: David Holmes <dholmes@openjdk.org> Date: 2020-12-07 21:56:05 +0000 URL: https://git.openjdk.java.net/jdk/commit/149a02f9
07-12-2020
[~alanb] thinks runtime have historically owned this code even though it lives in the JDK code base, not hotspot, so I've moved it there.
02-12-2020

CSR :	JDK-8257573 - Deprecate the archaic signal-chaining interfaces: sigset and signal
Relates :	JDK-8257643 - Remove the archaic signal-chaining interfaces: sigset and signal
Relates :	JDK-4381843 - Should use "signal-chaining" when replacing user signal handlers in JVM
Relates :	JDK-8257467 - [TESTBUG] -Wdeprecated-declarations is reported at sigset() in exesigtest.c

JDK-8257645 :	VM Guide: Document the deprecation in the signal chaining facility - Resolved
JDK-8257795 :	Release Note: Parts of the Signal-Chaining API Are Deprecated - Resolved