httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: night of the dead Apache
Date Sat, 01 Nov 1997 21:33:33 GMT
Oh goddamn, the pthread standard sucks.  Look at this, this is from the
single unix specification (dig around on www.opengroup.com to find it,
it's essentially the posix spec):

    Thread termination does not release any application visible
    process resources, including, but not limited to, mutexes and file
    descriptors, nor does it perform any process level cleanup actions,
    including, but not limited to, calling any atexit() routines that
    may exist

But all may not be lost.  We can mask every signal except TERM, HUP,
and USR1 while we're in the critical section (and KILL of course).
Then we can properly release the mutex on receipt of those signals.
This would add two syscalls to the pthread case, and probably drop its
performance to something closer to fcntl() anyhow.  I'll go find my
timing program and make this change and post back.

Dean

On Fri, 31 Oct 1997, Roy T. Fielding wrote:

> >Is it possible that the parent is killing off the only child
> >that has the mutex lock, and that killing it doesn't free the lock?
> >...
> >which kills off the two children that were created during the
> >big sequence (not trussed).  One of those two had the mutex.
> >Hmmm, time to test USE_PTHREAD_SERIALIZED_ACCEPT.
> 
> Yup, that's the problem.  Changing back to USE_FCNTL_SERIALIZED_ACCEPT
> fixes it.  The fcntl mutex is unlocked when the child is killed, whereas
> the pthreads mutex appears to remain locked.  I'm not sure if we should
> try to fix it or just remove the code.  Dean?  Basically, we'd need
> a way to check in the child's HUP/USR1 handler whether or not it has the
> mutex and unlock it if it does.
> 
> ....Roy
> 


Mime
View raw message