httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <>
Subject Re: [PATCH] 1.3.x Solaris performance and SERIALIZED_ACCEPT
Date Tue, 02 Jan 2001 17:44:45 GMT
On Mon, 1 Jan 2001, Victor J. Orlikowski wrote:

> The problem in the pthread code stems from a race that occurs right
> after unlock (which is documented in the code). Should the child
> process be killed right after the pthread unlock, the code as-is
> catches the signal, and unlocks the mutex again, resulting in a double
> unlock, which pthread mutexes do not catch but Solaris mutexes do.

oh ew.  the problem then is that the cleanup should be
registered/unregistered on each acquisition/release of the mutex.  maybe
with ap_block_alarms() protection.

> Whether such a patch is something we would want to include or not is
> another issue on the table: do we want the average user to have to
> re-compile the kernel on FreeBSD or Linux to set MaxClients as high as
> they need if SysV sems are set as the default synchronization mechanism?

linux doesn't have a static sysv semaphore SEM_UNDO limit.  and i've
already configured sysv sems as the default on linux (as per request of
the linux-kernel folks).  linux does have a static 256 or 512 per-user
process limit (it may actually be boot-time configurable lately i haven't


View raw message