DragonFly BSD
DragonFly submit List (threaded) for 2004-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Wed, 31 Mar 2004 21:16:02 -0800 (PST)

: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@xxxxxxxxxxxxx>



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]