patch to make script(1) exit cleanly on reciept of signal
Matthew Dillon
dillon at apollo.backplane.com
Wed Mar 31 21:16:46 PST 2004
:OK, inspiration hit me while rethinking this!
:
:Since we already have a pointer that may be pointing to the timeout, or
:may be NULL, it occurred to me - why not, instead of having the signal
:handler alter the timeout, just have it alter the pointer?
Ick. Just make the timeout unconditional... make it so it *always*
has a timeout.
:This surely handles the case where the user specified a flushtime of
:zero, because the pointer changes rather than the (unused in the case of
:flushtime == 0) struct timeval.
We do not have to support a flushtime of 0. If you want to allow
0 to be specified, just force it to be 1 in the code.
:I also think (emphasis on THINK) this means that we don't need the
:interlock. The mainline code can change tv to it's heart's content
:while the signal handler changes tvp. Whether the signal happens before
:or after the mainline code sets the timeout, when select() is called it
:uses tvp, which will point to the timeout (or NULL) if a signal hasn't
:happened, and will point to a zero-timeout structure if it has happened.
I suppose you could do this. It isn't good coding practice because
it makes the timeout structure non-determinstic everywhere in the code
instead of just within the interlocked section.
:The new patch is at the above URL.
:
:-Chris
-Matt
Matthew Dillon
<dillon at xxxxxxxxxxxxx>
More information about the Submit
mailing list