Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
On 7/12/2020 11:35 pm, Erik Joelsson wrote: On 2020-12-04 21:22, David Holmes wrote: Hi Erik, On 4/12/2020 12:07 am, Erik Joelsson wrote: In general, I would prefer if a flag like this was just inlined in the SetupJdkLibrary call, as there are no complex conditionals for setting it. Looking a bit further, the variable LIBJSIG_CFLAGS is dead and not set anywhere in the build, so could also just be removed and replaced with your new -D flag. I thought about just inlining it but it seemed "obvious" that LIBJSIG_CFLAGS existed exactly for this purpose, so I simply set it there - taking care to expand it in case it was set directly on the command-line. It also followed what is done for LIBJLI_CFLAGS. I can change it if you insist but this code will be very short-lived as I can remove it again in 17 once I no longer need the deprecation warning. If you think there is a case for overriding this on the command line, then sure, we can keep it. From what I can see, this is just a left over from when some more complicated logic was needed, or these flags needed to be reused somewhere else. In the case of libjli, we reuse the flags in several different versions of the SetupJdkLibrary call for libjli. That said, I won't insist strongly on this. Thanks Erik I appreciate that as I just want to get this pushed ASAP. David /Erik
Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: > 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. > > A CSR request has been filed. > > Testing: hotspot/jtreg/runtime/signal tests > > Thanks, > David Marked as reviewed by erikj (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1587
Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
On 2020-12-04 21:22, David Holmes wrote: Hi Erik, On 4/12/2020 12:07 am, Erik Joelsson wrote: In general, I would prefer if a flag like this was just inlined in the SetupJdkLibrary call, as there are no complex conditionals for setting it. Looking a bit further, the variable LIBJSIG_CFLAGS is dead and not set anywhere in the build, so could also just be removed and replaced with your new -D flag. I thought about just inlining it but it seemed "obvious" that LIBJSIG_CFLAGS existed exactly for this purpose, so I simply set it there - taking care to expand it in case it was set directly on the command-line. It also followed what is done for LIBJLI_CFLAGS. I can change it if you insist but this code will be very short-lived as I can remove it again in 17 once I no longer need the deprecation warning. If you think there is a case for overriding this on the command line, then sure, we can keep it. From what I can see, this is just a left over from when some more complicated logic was needed, or these flags needed to be reused somewhere else. In the case of libjli, we reuse the flags in several different versions of the SetupJdkLibrary call for libjli. That said, I won't insist strongly on this. /Erik
Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
On Sat, 5 Dec 2020 15:23:38 GMT, Thomas Stuefe wrote: >> Thumbs up on the jsig.c change. No comment on the Lib.gmk change. > > Hi David, > > I am fine with this, but since this is possibly a breaking change would this > not need a release note? > > ..Thomas > > > > Hi David, > > I am fine with this, but since this is possibly a breaking change would > > this not need a release note? > > Well it isn't breaking anything at this stage as we are just issuing a > deprecation warning. :) But yes I have filed a release note as well. > > Thanks, > David Hi David, :) Thanks. The warning might elude customers until JDK17 comes around and things stop working. With signal chaining being out of scope for the typical java consultant, the expertise may have gone so customers may need to look for someone changing and recompiling their native solution. Or bug vendors to do so. Cheers, Thomas - PR: https://git.openjdk.java.net/jdk/pull/1587
Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
Hi Thomas, On 6/12/2020 1:26 am, Thomas Stuefe wrote: On Thu, 3 Dec 2020 14:40:26 GMT, Daniel D. Daugherty wrote: 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. A CSR request has been filed. Testing: hotspot/jtreg/runtime/signal tests Thanks, David Thumbs up on the jsig.c change. No comment on the Lib.gmk change. Hi David, I am fine with this, but since this is possibly a breaking change would this not need a release note? Well it isn't breaking anything at this stage as we are just issuing a deprecation warning. :) But yes I have filed a release note as well. Thanks, David ..Thomas - PR: https://git.openjdk.java.net/jdk/pull/1587
Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
On Thu, 3 Dec 2020 14:40:26 GMT, Daniel D. Daugherty wrote: >> 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. >> >> A CSR request has been filed. >> >> Testing: hotspot/jtreg/runtime/signal tests >> >> Thanks, >> David > > Thumbs up on the jsig.c change. No comment on the Lib.gmk change. Hi David, I am fine with this, but since this is possibly a breaking change would this not need a release note? ..Thomas - PR: https://git.openjdk.java.net/jdk/pull/1587
Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
On 4/12/2020 12:42 am, Daniel D.Daugherty wrote: On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: 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. A CSR request has been filed. Testing: hotspot/jtreg/runtime/signal tests Thanks, David Thumbs up on the jsig.c change. No comment on the Lib.gmk change. Thanks for the review Dan! David - Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1587
Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
Hi Erik, On 4/12/2020 12:07 am, Erik Joelsson wrote: On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: 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. A CSR request has been filed. Testing: hotspot/jtreg/runtime/signal tests Thanks, David make/modules/java.base/Lib.gmk line 131: 129: ifeq ($(call isTargetOsType, unix), true) 130: ifeq ($(STATIC_BUILD), false) 131: LIBJSIG_CFLAGS += -DHOTSPOT_VM_DISTRO='"$(HOTSPOT_VM_DISTRO)"' In general, I would prefer if a flag like this was just inlined in the SetupJdkLibrary call, as there are no complex conditionals for setting it. Looking a bit further, the variable LIBJSIG_CFLAGS is dead and not set anywhere in the build, so could also just be removed and replaced with your new -D flag. I thought about just inlining it but it seemed "obvious" that LIBJSIG_CFLAGS existed exactly for this purpose, so I simply set it there - taking care to expand it in case it was set directly on the command-line. It also followed what is done for LIBJLI_CFLAGS. I can change it if you insist but this code will be very short-lived as I can remove it again in 17 once I no longer need the deprecation warning. Thanks, David - PR: https://git.openjdk.java.net/jdk/pull/1587
Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: > 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. > > A CSR request has been filed. > > Testing: hotspot/jtreg/runtime/signal tests > > Thanks, > David Thumbs up on the jsig.c change. No comment on the Lib.gmk change. - Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1587
Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: > 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. > > A CSR request has been filed. > > Testing: hotspot/jtreg/runtime/signal tests > > Thanks, > David make/modules/java.base/Lib.gmk line 131: > 129: ifeq ($(call isTargetOsType, unix), true) > 130: ifeq ($(STATIC_BUILD), false) > 131: LIBJSIG_CFLAGS += -DHOTSPOT_VM_DISTRO='"$(HOTSPOT_VM_DISTRO)"' In general, I would prefer if a flag like this was just inlined in the SetupJdkLibrary call, as there are no complex conditionals for setting it. Looking a bit further, the variable LIBJSIG_CFLAGS is dead and not set anywhere in the build, so could also just be removed and replaced with your new -D flag. - PR: https://git.openjdk.java.net/jdk/pull/1587
Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
On 3/12/2020 9:26 pm, Alan Bateman wrote: On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: 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. A CSR request has been filed. Testing: hotspot/jtreg/runtime/signal tests Thanks, David Marked as reviewed by alanb (Reviewer). Thanks for the Review Alan! David - PR: https://git.openjdk.java.net/jdk/pull/1587
Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
On 3/12/2020 9:19 pm, Magnus Ihse Bursie wrote: On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: 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. A CSR request has been filed. Testing: hotspot/jtreg/runtime/signal tests Thanks, David As we say in Swedish: Äntligen! :-) Build changes look good. Thanks for the review Magnus! David - - Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1587
Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: > 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. > > A CSR request has been filed. > > Testing: hotspot/jtreg/runtime/signal tests > > Thanks, > David Marked as reviewed by alanb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1587
Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: > 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. > > A CSR request has been filed. > > Testing: hotspot/jtreg/runtime/signal tests > > Thanks, > David As we say in Swedish: Äntligen! :-) Build changes look good. - Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1587
RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
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. A CSR request has been filed. Testing: hotspot/jtreg/runtime/signal tests Thanks, David - Commit messages: - 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal Changes: https://git.openjdk.java.net/jdk/pull/1587/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1587&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257572 Stats: 7 lines in 2 files changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1587.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1587/head:pull/1587 PR: https://git.openjdk.java.net/jdk/pull/1587
