Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Message-ID: <017d01c0e945$0861db60$71431b09@sashimi>
From: "Bill Stoddard" <bill@wstoddard.com>
To: <new-httpd@apache.org>
References: <m3elt6y7tn.fsf@adsl-77-241-65.rdu.bellsouth.net>
Subject: Re: idle server processes not going away
Date: Wed, 30 May 2001 16:13:46 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I cannot believe the lock calls don't already return EINTR. That seems to be an okay
solution... Here is another solution I was an advocate for at least 1 1/2 years ago...

Don't APRize the accept/select locking.

And here is one real life scenario to demonstrate... Many (most?) Apache users running
Apache on Solaris with Netegrity Siteminder have problems with Apache going belly up (not
serving requests) because of a failure in the default FCNTL locking in Apache 1.3.
Netegrity's advise to their customers is to use SYSV_SEM locking rather than FCNTL
locking. If we use APR'ized locks, then all Apache mutexs are changed from FCNTL to
SYSV_SEM with this change.  This is not good. I believe the accept/select locking is
specialized enough to merit handling outside of APR.

Bill

> This is easy to see with prefork and a config or platform which
> requires serialization around select/accept.
>
> Pound on apache to create some extra server processes then stop
> pounding and take a look at the server-status page (or the output of
> ps).  A bunch of processes will stay in 'I' (SERVER_IDLE_DIE) state
> indefinitely.  They know they need to go away because the signal
> handler ran but they are stuck waiting on the accept mutex.
>
> To get rid of them you need to pound on the server some more.
>
> We ran into problems before because we were doing too much in the
> signal handler.  Now perhaps we're not doing enough?
>
> possibilities
>
> . do more stuff in the signal handler or call [sig]longjump() to get
>   back to the main flow; unfortunately, this may not be better
>   than the old logic to do a bunch of stuff in the signal handler
>   because we don't know what mutexes we're holding or what other sorts
>   of cleanups are needed; I'm not sure we can trust pool cleanups to
>   solve all problems here
>
> . make the mutex lock call return EINTR and then go back to the top of
>   the loop and find out that we're supposed to go away
>
>   we'd assume that if it is somewhere besides the mutex lock then it
>   is about to exit anyway
>
>   (this seems to be the least risky, but is ugly from the APR point of
>   view since EINTR isn't a common concept)
>
> . ???
>
> --
> Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
>        http://www.geocities.com/SiliconValley/Park/9289/
>              Born in Roswell... married an alien...
>