Improve registering signal handlers in java.lang.Terminator.setup()
Alan.Bateman at oracle.com
Fri Aug 17 08:58:07 UTC 2012
On 16/08/2012 16:32, Neil Richards wrote:
> First, I think the discussion on the particular VM implementation
> behaviour is a slight diversion from Frank's suggested change, which I
> believe is all about making the Java code more robust / agnostic to the
> VM implementation behaviour.
I think it was important to get some context as it was missing in the
> > From the perspective of the code in Terminator.setup(), I think the
> pertinent question is:
> Should the code try to register shutdown hook handlers for other
> signals if the attempt to register for one signal fails with an
> Or, to put it another way:
> Should the registration of the shutdown hook handler for each
> signal be independent of each other?
> Frank's suggested change, and my argument, is that these registrations
> should be independent - i.e. that Terminator.setup() should register
> shutdown hook handlers for all (shutdown) signals that the system (VM)
> allows it to.
I think we're in agreement on that.
On JVM_RegisterSignal then it returns -1 if the signal is in use by the
VM or there is an error examining/changing the action. If the signal is
ignored (existing action is SIG_IGN) then it just returns SIG_IGN
without attempting to change it. It probably should have defined a
specific error for this case as the caller can't distinguish it from the
case that the action was changed and the previous action was SIG_IGN. If
there was an error for this case then sun.misc.Signal could have mapped
it to an exception, perhaps IllegalStateException. Whether it's worth
changing this now isn't clear to me but changing it is potentially
disruptive. Disruptive meaning that it would change the behavior of
sun.misc.Signal so that it would throw an exception for a case where it
doesn't do so today. Folks shouldn't be using sun.misc.Signal of course
but we know that they do.
> However, I still consider that VM modification would be logically
> orthogonal to Frank's suggested change, and suggest that his change
> could continue to be approved for contribution at this point, regardless
> of the separate VM-related discussion in this area.
Both David and I have already reviewed Frank's change and okay with it.
I'll leave it to you whether you want to propose a change to
More information about the core-libs-dev