Re: [PATCH] 1.3.x Solaris performance and SERIALIZED_ACCEPT

["Victor J. Orlikowski" <v....@gte.net>]

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.

Solaris has boot-time limits on SysV semaphores (modify desired values
in /etc/system, and reboot). Linux and FreeBSD have compile-time
limits. Holidays have sidetracked me from a patch to detect the limits
in the various OSes, and write errors to the log if the limits do not
correspond in a reasonable manner to MaxClients (especially since
determining the limits at run-time differs for each OS).

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?

Victor
-- 
Victor J. Orlikowski
======================
v.j.orlikowski@gte.net
vjo@raleigh.ibm.com
vjo@us.ibm.com

Re: [PATCH] 1.3.x Solaris performance and SERIALIZED_ACCEPT

[dean gaudet <dg...@arctic.org>]

On Tue, 2 Jan 2001, Victor J. Orlikowski wrote:

> In the 2.4 kernels, the process limit is run-time configurable
> (i.e. echo > "100000" /proc/sys/kernel/max-threads does the
> adjustment). In 2.2 kernels, you have to edit
> /usr/src/linux/include/linux/tasks.h and re-compile.
>
> My apologies on the SEM_UNDO limit on linux. You're in the right
> there. However, what would we like done for those OSes which have this
> limit? Should we simply assume that the admin is clueful?

no i'd say use the slower fcntl/flock methods and let the clueful admin
recompile apache and their kernels.  let those OS folks take the heat by
virtue of crap apache performance on their system.

-dean

Re: [PATCH] 1.3.x Solaris performance and SERIALIZED_ACCEPT

["Victor J. Orlikowski" <v....@gte.net>]

In the 2.4 kernels, the process limit is run-time configurable
(i.e. echo > "100000" /proc/sys/kernel/max-threads does the
adjustment). In 2.2 kernels, you have to edit
/usr/src/linux/include/linux/tasks.h and re-compile.

My apologies on the SEM_UNDO limit on linux. You're in the right
there. However, what would we like done for those OSes which have this
limit? Should we simply assume that the admin is clueful?

Victor
-- 
Victor J. Orlikowski
======================
v.j.orlikowski@gte.net
vjo@raleigh.ibm.com
vjo@us.ibm.com

Re: [PATCH] 1.3.x Solaris performance and SERIALIZED_ACCEPT

[dean gaudet <dg...@arctic.org>]

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
checked).

-dean