Improve registering signal handlers in java.lang.Terminator.setup()
Neil Richards
neil.richards at ngmr.net
Tue Aug 7 14:02:11 UTC 2012
On Tue, 2012-08-07 at 10:15 +0100, Alan Bateman wrote:
> On 07/08/2012 04:35, David Holmes wrote:
> >
> > The change is harmless but as far as I can see you would have to
> > customize the VM before this change would have any affect. The signals
> > involved here are the SHUTDOWNn_SIGNAL values (which for linux/solaris
> > are HUP, INT and TERM). JVM_RegisterSignal simply does:
> >
> > case SHUTDOWN1_SIGNAL:
> > case SHUTDOWN2_SIGNAL:
> > case SHUTDOWN3_SIGNAL:
> > if (ReduceSignalUsage) return (void*)-1;
> > if (os::Linux::is_sig_ignored(sig)) return (void*)1;
> > }
> >
> > So with -Xrs all values will get rejected as a group. As far as I can
> > see this is the only time that -1 will be returned to Signal.handle0
> > and hence the only circumstance where IllegalArgumentException will be
> > thrown. So without customizing the VM if any of these signals cause
> > IllegalArgumentException then they all will and hence having distinct
> > try/catch blocks for each is pointless.
> >
> > Did I miss something?
> I agree with David and I think this thread is just missing an
> explanation as to how you ran into this. It this AIX and -Xrs is mapped
> to a different set of signals, maybe it was an observation when reading
> the code??
>
> -Alan.
>From a Java Class Library point of view, it seems to me that the desire
is to register shutdown hooks for any of these signals (HUP, INT and
TERM) whose use has not been restricted by the VM.
So an attempt to register for each of these signals should be made,
independent of the result of any of the other attempts.
To do anything else builds into the Java class library code assumptions
about the behaviour of the VM which are inherently implementation
(version?) specific, which is a brittle thing to do.
It currently assumes that the VM will either have restricted all these
signals (the -Xrs case) or none of them.
This assumption holds true for the current version of Hotspot VM, but
not necessarily for other VM implementations, whose mix of signal usage
may differ.
So I think Frank's suggested change helps this code to adhere the VM /
Class Library interface boundary, and so makes it less brittle.
Regards,
Neil
--
Unless stated above:
IBM email: neil_richards at uk.ibm.com
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
More information about the core-libs-dev
mailing list