"Bill Stoddard" <[EMAIL PROTECTED]> writes: > > 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 :) -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
