TASK_KILLABLE

Posted Jul 3, 2008 3:55 UTC (Thu) by jwb (guest, #15467)
Parent article: TASK_KILLABLE

This is a great idea.  Signals are the worst, stupidest part of Unix (yes, they are even more
stupid than creat) and EINTR has a long history of exposing errors in programs.  I have never
seen any program which I could confidently claim handles all signals correctly.  The nature of
the asynchronous delivery and the completely undefined state of the program which takes the
signal makes it impossible to prove or even convincingly demonstrate that Unix programs are
correct in this regard.

I'd be very happy to see Linux moving over to the BSD kqueue API, where signals are handled in
a program's main i/o loop instead of being delivered to magical handlers.  This greatly
simplifies the programming and makes it possible to have confidence in the correctness of a
program.

to post comments

TASK_KILLABLE

Posted Jul 3, 2008 5:17 UTC (Thu) by zlynx (guest, #2285) [Link] (1 responses)

signalfd is what you're looking for, although I'm not clear on its merge status.

signalfd

Posted Jul 3, 2008 13:43 UTC (Thu) by i3839 (guest, #31386) [Link]

Assuming the signalfd manpage can be trusted, RTFM. ;-)

> signalfd()  is available on Linux since kernel 2.6.22.  Working support
> is provided in glibc since version 2.8.

agree

Posted Jul 3, 2008 13:27 UTC (Thu) by alex (subscriber, #1355) [Link]

I can only nod in agreement having spent many-many hours trying to get signal handling behave
in an above-the-os DBT. The number of corner cases is quite surprising.