Messages in this thread | | | Date | Mon, 28 Jun 2004 14:55:55 -0700 (PDT) | From | Davide Libenzi <> | Subject | Re: [patch] signal handler defaulting fix ... |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |