httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <hart...@ooo.lanl.gov>
Subject Re: Serialising accepts (was Re: apache_0.7.3h comments)
Date Tue, 27 Jun 1995 11:43:26 GMT

David writes,

>I think we should bite the bullet and admit that use of multiple accepts is not
> portable, and that we have to re-work it to explicitly serialise the accepts
> in a portable manner.

that's never been denied, however it was only assumed that MP systems
would be the only ones which need to be mutually excluded from doing
an accept.

> The alternative is to have ad hoc serialisation for each OS that needs it,
> possibly in a manner that is OS minor-version-number specific. For these
> OS's (and how will we know if an OS breaks until the users complain?) the
> ad hoc serialisation will probably be no faster than some portable schemes
> we could implement. For example, lockf() is actually implemented via IPC
> to a lockd daemon; IPC to the parent httpd would not be any slower.

I really dislike the idea of involving the parent in this process. If
the children (on the affected systems) can do the job themselves, then
that must be the best way.

> So:
>  The parent has a pipe to each child.
>  It sends a short message to an idle child saying: 'you accept next'.
>  On completing a request a child sends a message to the parent saying
>  'I am idle', and waits for a response message.

This was the mothod I used to prototype a pre-forker with perl. It
works, but I'm sure that OS systems for mutual exclusion will be
much more efficient than parent<->child communication. As a last
resort, maybe.

>  The parent has some algorithm for deciding which idle child should be
>  given the next connection. Round-robin would be cache-unfriendly; instead,
>  send it to the most recently used child.

Systems which are happy to do multiple accepts; SunOs and HPUX appear to
be, should be allowed to just get on with things and not have to get
involved in parent scheduling algorithms which will only slow it down.

As a final note, I'd sooner trust an OS based mutual exclusion system
than one involving apache interprocess communication.


rob
--
http://nqcd.lanl.gov/~hartill/

Mime
View raw message