> > > But this bites > > > > > > 1) when there is just one child process (wasted syscall) > > > > > > 2) because it would normally go faster if the listener could stay just > > > ahead of the workers so that workers can dequeue new work when they > > > finish with the old without having to wait on the listener to > > > enqueue something > > > Sounds like a reasonable solution. I doubt you could measure the > performance difference > > due to a wasted syscalls. 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. > > agreed... > > 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. Ryan
