JDK-8257643 : Remove the archaic signal-chaining interfaces: sigset and signal
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 17
  • Priority: P4
  • Status: Resolved
  • Resolution: Future Project
  • Submitted: 2020-12-03
  • Updated: 2021-04-07
  • Resolved: 2021-04-07
Related Reports
Relates :  
Sub Tasks
JDK-8257653 :  
JDK-8257572 deprecated sigset and signal usage with an intent to remove - which we now do.
Based on further feedback around concerns that this may impact ancient, but still operational, native libraries, I have decided to defer this until such time as it actually causes a build/link problem for the VM. Closing as "Future Project".

In JDK-8257572: Thomas Stuefe added a comment - 2020-12-11 16:50 - edited 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. --- The deprecation did proceed in 16 as I think we need to flag that people need to move their code on, but based on Thomas's feedback I have decided to defer the removal to JDK 18.