You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Roy T. Fielding" <fi...@kiwi.ics.uci.edu> on 1997/11/06 03:42:35 UTC

Re: [PATCH] make SVSEM default on Solaris

>Oh BTW Roy, if you're going to time fcntl then you should "cd /var/tmp"
>or otherwise make sure your cwd is not NFS mounted ... 'cause that's
>where the lock file will be created.  I just added a printf for that.

All of my tests were on a local disk.  fcntl works but is visibly slower
in exchanging locks than SVSEM.  I don't believe the denial of service
attack is reasonable -- a CGI script smart enough to steal the semop
forever (and not get killed by the parent) is smart enough to fork
a thousand processes or do any of a million other things to bring down
a server.

What we need is a multi-child stress tester pointing at a real Apache
server for several hours and see if anything shakes loose.  I'll set
FCNTL as the default in conf.h, but every test I've run shows SVSEM to
be running at least as fast as PTHREAD and without losing a single lock.

BTW, it would probably be a good optimization for the parent to kill
the oldest children when there are too many idle servers.  We currently
kill the youngest children, which makes it far more likely that the
child with the mutex lock will get killed.  OTOH, it does make it easier
to test these bugs.

....Roy

Re: [PATCH] make SVSEM default on Solaris

Posted by Dean Gaudet <dg...@arctic.org>.

On Wed, 5 Nov 1997, Roy T. Fielding wrote:

> BTW, it would probably be a good optimization for the parent to kill
> the oldest children when there are too many idle servers.  We currently
> kill the youngest children, which makes it far more likely that the
> child with the mutex lock will get killed.  OTOH, it does make it easier
> to test these bugs.

Yeah it'd be easy to switch ... I never did any work to see if there was
an advantage to either method.  We actually just kill the highest numbered
child... which is usually pretty young, but not necessarily.

Dean