[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 
> timeouts.

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:

      else
        {
	  timer_val.tv_sec = timer_val.tv_usec = 0;
          timer_wait = &timer_val; /* 0 timeout */
        }

Regards,
Andy



More information about the Quagga-dev mailing list