Improve registering signal handlers in java.lang.Terminator.setup()

Alan Bateman Alan.Bateman at
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 
original mails.

> > 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
>          exception?
> 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 mailing list