[quagga-dev 8589] Re: [PATCH] fix thread timer regression in 0.99.18

paul at jakma.org paul at jakma.org
Thu Mar 24 11:52:54 GMT 2011


On Wed, 23 Mar 2011, Stephen Hemminger wrote:

> The problem is that even if one or more threads are waiting on I/O 
> the select still needs to wakeup sooner to process any timer events 
> (like OSPF timeouts, BGP keepalives, ...). The new scheduler was 
> not waking up and always waiting for the other side to respond.

Hmm.. What's the bug exactly?

> --- a/lib/thread.c	2011-03-23 16:16:33.073899445 -0700
> +++ b/lib/thread.c	2011-03-23 16:17:31.114943809 -0700
> @@ -1012,9 +1012,9 @@ thread_fetch (struct thread_master *m, s
>   fd_set readfd;
>   fd_set writefd;
>   fd_set exceptfd;
> -  struct timeval timer_val = { .tv_sec = 0, .tv_usec = 0 };

> -      if (m->ready.count == 0)
> -        {
> -          quagga_get_relative (NULL);
> -          timer_wait = thread_timer_wait (&m->timer, &timer_val);
> -          timer_wait_bg = thread_timer_wait (&m->background, &timer_val_bg);
> -
> -          if (timer_wait_bg &&
> -              (!timer_wait || (timeval_cmp (*timer_wait, *timer_wait_bg) > 0)))
> -            timer_wait = timer_wait_bg;
> -        }

>       num = select (FD_SETSIZE, &readfd, &writefd, &exceptfd, timer_wait);

Basically, if we know there are event threads ready, then we poll 
select (immediate timeout), after which we still queue up all the 
signals, timers and IO onto the ready list.

With this change, it seems to me nothing changes, except we'll sit in 
select until the next timer is due - all the while with event threads 
pending.

I suspect, if there is a bug, it must be elsewhere. E.g. 
thread_timer_process not coping with very short (potentially 0) 
difference in time somehow?

regards,
-- 
Paul Jakma  paul at jakma.org  twitter: @pjakma  PGP: 64A2FF6A
Fortune:
Excusing bad programming is a shooting offence, no matter _what_ the
circumstances.
 	-- Linus Torvalds, to the linux-kernel list



More information about the Quagga-dev mailing list