[quagga-dev 3296] Re: [PATCH] non-blocking I/O from client daemons tozebra
Andrew J. Schorr
aschorr at telemetry-investments.com
Thu Apr 21 21:49:52 BST 2005
On Thu, Apr 21, 2005 at 09:20:13PM +0100, Paul Jakma wrote:
> >3. In your "eek" cases, why do you set the timer to 10 microseconds
> >instead of 0 microseconds?
> To prevent a repeated error in a timeval causing the scheduler to
> spin around and around. I did this by accident when i passed the
> pointer as argument and got a continious stream of selects with 0
Perhaps I'm confused, but I don't see why those "eek" cases are bugs
that should be logged with zlog_err. Isn't it prefectly reasonable
to have a timer event give a negative timeout if the machine is bogged
down and not processing timer events quickly enough? IMHO, in such a
case, the timeout should be corrected to 0, not 10 microseconds
(and there should be no error message). Am I missing something?
> >5. I believe that select can change the value in the struct
> >timeval, so it is possible that the contents of timer_nowait may be
> >changed by the call to select.
> Yes, I realised that, old version of the patch ;). See above.
> Actually, why does it both take a struct timeval and return it? It
> confused my poor tired brain the other night.
> >Therefore, it would be wise to reinitialize timer_nowait before
> >using it. Actually, there's no reason to have a timer_wait
> >veraible at all, just set timer_val to 0 in that case.
> timer_nowait you mean? that can go, the timer_wait pointer is needed.
I think the current version is not safe. If you want a 0 timeout,
you need to set timer_val to 0 first:
timer_val.tv_sec = timer_val.tv_usec = 0;
timer_wait = &timer_val; /* 0 timeout */
More information about the Quagga-dev