Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Sun, 31 Dec 2000 09:39:09 -0800 (PST)
From: dean gaudet <dgaudet-list-new-httpd@arctic.org>
To: <new-httpd@apache.org>
Subject: Re: [PATCH] 1.3.x Solaris performance and SERIALIZED_ACCEPT
In-Reply-To: <14903.48909.744955.640433@critterling.garfield.home>
Message-ID: <Pine.LNX.4.30.0012310934240.26920-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Bill Stoddard asks:
	Any objections setting default to USE_SYSVSEM_SERIALIZED_ACCEPT on
	Solaris?

yeah i don't think they should be used.  victor points out why a few weeks
later.  they require the admin to reconfigure their system -- there's a
static boot-time limit, or some insanity.  if you dig through the
new-httpd archives several years ago you'll find my analysis of the
various locking primitives.

On Wed, 13 Dec 2000, Victor J. Orlikowski wrote:

> The following is a patch to use solaris native mutexes for locking, to
> improve performance on Solaris. They are slightly slower than pthread
> mutexes, but do not misbehave if unlocked twice, eliminating the race
> resulting from pthread mutexes. Further, they do not need any special
> configuration, unlike SysV sems and like pthread mutexes.

this seems like a fine thing to try... hopefully you can get some folks
to try it live before putting it into 1.3.15 though.

so is it just a double-unlock problem?  do we do something stupid like
release the semaphore during fork/exec?

i always thought it was because a process exiting without releasing the
mutex would leave it locked... because there's no kernel record of who
has the locks.  whereas with fcntl() and sysvsems the kernel keeps track
of who has the locks and frees them at process exit (it's why both of
these are slow).

-dean