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