On Thu, 11 Apr 2002, Ryan Bloom wrote: > > > And you can always play some games with the counters to enable you > > > to accept a few additional connections (however you define 'few') > > > in order to keep some work in the queue. > > > > It just is hard to think about what "few" should be given that there > > is always a spastic case (all threads handling large DAV transactions > > from deep space probes). But in practice the normal definition of > > "few" should be fine :) > > I was thinking that the definition of "few" could be a directive.
My take on it is that any non-zero fixed number, configurable or not, is just as wrong as any other, in the sense that it does not eliminate the problem, it just just changes how many clients can be affected by it. That said, I think the idea of shortening the queue would help. It most likely doesn't need to be as big as the number of worker threads. However, it's hard to say what "the right length" is, because that number changes dynamically. Ideally, the listener thread would be able to tell how long its workers spent on requests on average, and adjust the queue length dynamically in a sort of feedback loop. That way the listener thread will always have work to do for for the workers as absolutely soon after the finish the last one as possible (that's the point of the per-process queue as I understood it), and it allows listeners who know that their workers are all tied up to avoid shanghaiing more clients than they expect to be able to deal with in the near future. Just a thought. --Cliff -------------------------------------------------------------- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
