Re: patch to make script(1) exit cleanly on reciept of signal

[Chris Pressey <cpressey@xxxxxxxxxxxxxxx>]

On Sat, 27 Mar 2004 23:22:20 -0800 (PST)
Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> wrote:

>     Signal handlers are difficult to do right.  So, for example, what
>     happens if the signal were to occur just *BEFORE* the select() ?
>     The answer is: script would not exit at all.

Matt, I know you are far wiser than I in the ways of the race condition
- so forgive me if I remain a bit skeptical.

I can see why script might not exit immediately, but I fail to see why
it would not exit at all.

If a signal arrives just before select(), it sets sigtermed, then goes
into the select().  The select() would (as I understand it) wait for one
of the file descriptors to do something (say, for the user to hit a
key,) and when it returned, script would exit, as sigtermed would still
be set.

(Obviously, this is still a good reason to use your option #2, to make
it immediate, instead of waiting for the user to press a key.)

Experientially, the behaviour seems even slightly different than this.
If I insert a sleep() statement directly before the select(), and send
it a signal during the sleep, it DOES exit immediately!

I thought this might be because the child, as part of the process group,
receives the signal too, and terminates, causing the select() to
immediately read an EOF from it and return.

BUT, that can't be it, because the same behaviour (exiting immediately)
occurs when the child is a program which is itself ignoring signals!

So there's definately something I'm not understanding here...

-Chris