Right, the problem is that the listener needs to avoid doing the accept if the queue is full.
That part is easy: add a "block_if_queue_full()" method on the fd_queue class, and have the listener call it before doing an accept. But there are two negative side-effects: * More contention on a global mutex. (This one, IMHO, is bad but not a showstopper. The worker design already has way too much mutex contention, and the real solution is to move on to a new MPM design, so for now I won't object to adding one more lock/unlock pair.) * If there's anything in the shutdown/restart logic that assumes that the listener will always do an accept in a timely manner, that code will break in cases where the listener is blocked waiting for the queue to become non-full. (I'm not sure if this one is a problem in reality or not.) --Brian Bill Stoddard wrote: >Nope. I that that back. This would not fix anything... > >Bill > >>A quick and dirty hack that would fix this problem is to reduce the queue size to >>ThreadsPerChild/2. >> >>Bill >> >> >>>On Thu, Apr 11, 2002 at 07:33:40AM -0700, Brian Pane wrote: >>> >>>>I disagree. Unless someone wants to volunteer to put a workaround >>>>in the current worker code to fix the queue-full case, I can't >>>>rationalize including it in another beta or GA release. We need >>>>to either fix it or remove it. >>>> >>>I volunteer to fix it. >>> >>>-aaron >>>
