JDK-8257573 : Deprecate the archaic signal-chaining interfaces: sigset and signal
  • Type: CSR
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P3
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 16
  • Submitted: 2020-12-02
  • Updated: 2020-12-04
  • Resolved: 2020-12-04
Related Reports
CSR :  
JDK-8257572 - Deprecate the archaic signal-chaining interfaces: sigset and signal
Description
Summary
-------

Deprecate the archaic signal-chaining interfaces sigset and signal, with a view to remove them in JDK 17.

Problem
-------

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.

Solution
--------

Deprecate the use of `sigset` and `signal` with a view to removing them in JDK 17.

Specification
-------------

There is no actual specification for this functionality, only the documentation in the VM guide which we no longer seem to produce.

If the user invokes the `sigset` or `signal` functions in the signal chaining library, then we will issue a deprecation warning. e.g.

> `The use of the sigset function is deprecated and will be removed in a future release. Use the sigaction function instead.`
Comments
I see a release note is already planned. Note to Dr. Deprecator via [~smarks] for an unusual case on the deprecation rounds. Moving to Approved.
04-12-2020
Okay, I read the CSR as just the deprecation of the feature and that there would be a follow on CSR for JDK 17 (or later) once there is time for any remaining users to come out of the woodwork.
03-12-2020
The intent is to remove in 17 so the CSR (as per hotspot flag process) was intended to cover the deprecation and later removal. Though I could file a separate CSR for the removal in 17.
03-12-2020
Legacy mechanism, the only behavioural change is a deprecation warning at run-time.
03-12-2020
I've added a doc subtask to the main issue to have the VM Guide updated, as its seems we do continue to provide it. e.g. https://docs.oracle.com/en/java/javase/15/vm/signal-chaining.html#GUID-CB49A2A7-2A9F-4C18-948F-6D4A96FF688D
03-12-2020
Thanks for the review [~dcubed]!
03-12-2020