[quagga-dev 3259] Re: [PATCH] non-blocking I/O from client daemons tozebra

Andrew J. Schorr aschorr at telemetry-investments.com
Wed Apr 20 20:08:39 BST 2005


On Wed, Apr 20, 2005 at 07:52:42PM +0100, Paul Jakma wrote:
> both the normal synchronous and experimental queueing test cases hold 
> up well to hammering.

Cool.

> The vty is a bit laggy, like an ssh session to a far off host while 
> you're downloading the latest release of your favourite OS, but it's 
> still useable - more importantly, the daemon is still able to respond 
> to IO and other events in a timely fashion.

I guess you could improve interactive response by decreasing the amount
of work done in each background call, but that time slice threshold is a
judgement call that should perhaps be tuneable by the configure script.

> If we defer the question of whether the timer aspect of the 
> background thread is required, what do we think?

I generally think that we need background threads (or, alternatively,
a more general sense of thread priorities).  At the moment, it's probably
much easier just to add the background threads (as you have done).

> If I can get this dusted, I can move on to making the queue helper 
> api sensible. ;)

Well, I must confess that I am still not clear on why the whole workqueue
API is needed in addition to the background thread API.  Have you tried
implementing the heavy-wq sample program just using background threads directly
without using the workqueue API?  Is it really much worse?

Regards,
Andy

P.S. A few questions about your patch:

1. Why this?

 static unsigned int 
 cpu_record_hash_key (struct cpu_thread_history *a)
 {
-  return (unsigned int) a->func;
+  return ((unsigned long) a->func) & -1U;
 }

2. In funcname_thread_add_background, why initialize trel to 0 before
checking for a non-zero delay value?  Why not just set trel to 0 in an
else clause?

3. Are the various "eek" printouts going to be in the final patch committed? :-)

4. In thread_fetch, is it possible to get to the select call if ready is
positive?  Wouldn't we bail out a few lines above in this statement if
there were ready thread:

      /* If there are any ready threads, process top of them.  */
      if ((ready > 0) && (thread = thread_trim_head (&m->ready)) != NULL)
        return thread_run (m, thread, fetch);

To put it another way, if (ready > 0), is it possible for
thread_trim_head(&m->ready) to return NULL?  If not, then the logic
below is a bit muddled...



More information about the Quagga-dev mailing list