Aaron Bannert <[EMAIL PROTECTED]> writes:
> On Tue, Mar 05, 2002 at 09:23:30PM -0000, [EMAIL PROTECTED] wrote:
> > trawick 02/03/05 13:23:30
> >
> > Modified: . STATUS
> > Log:
> > axe the entry on graceful restart problems with worker
> >
> > I was too stupid to read the code to determine that the accept mutex
> > failure log messages were harmless and not indicative of a real problem.
> >
> > I'll try to understand the conditions where I'm seeing connections
> > dropped.
>
> I suspect these are one and the same problem.
What do you mean by "these"?
> When we get a failure
> while trying to acquire a mutex it probably means that the mutex was
> already destroyed. Is it possible that we also destroyed the fdqueue
> while there were connections waiting to be picked up by a worker?
worker threads exit as soon as workers_may_exit is set... I don't see
any logic to make sure we don't lose any accepted connections (stuff
in the queue)
so yes, it looks normal to destroy worker_queue without looking to see
if any accepted connections are in the queue
Once the listener thread realizes that we're terminating and it will
no longer call accept, it needs some way to trigger an error on the
queue so that once the last connection is dequeued by a worker thread
subsequent pop operations fail in a way that worker treads know they
should exit. And instead of exiting as soon as workers_may_exit is
set, worker threads should exit once they get the magic queue-is-dead
error from a pop operation.
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
