Re: [patch] signal handler defaulting fix ...

[Davide Libenzi <davidel@xmailserver.org>]

On Mon, 28 Jun 2004, Linus Torvalds wrote:

> On Mon, 28 Jun 2004, Andrew Morton wrote:
> >
> > Davide Libenzi <davidel@xmailserver.org> wrote:
> > >
> > > 
> > > Following up from the other thread (2.6.x signal handler bug) this bring 
> > > 2.4 behaviour in 2.6.
> > > 
> > 
> > Pity the poor person who tries to understand this change in a year's time. 
> > Could we have a real changelog please?
> 
> Also, do we really care? The 2.6.x behaviour is nicer in that it tends to
> kill programs more abruptly, while 2.4.x will just let a blocked signal
> through - possibly letting the program continue, but causing "impossible"  
> bugs in user space.
> 
> I don't think we've had any complaints about the 2.6.x behaviour apart
> from the initial discussion a few months ago. I'd much rather have a
> debuggable "kill a program that tries to block a synchronous interrupt",
> than a potentially totally un-debuggable "let the signal through".

It's not that the program try to block the signal. It's the kernel that 
during the delivery disables the signal. Then when the signal handler 
longjmp(), the signal remains disabled. The next time the signal is raised 
again, the kernel does not honor the existing handler, but it reset to 
SIG_DFL.



- Davide