Re: [apache-plusplus] Process model ideas for C++ Apache.

[Dean Gaudet <dgaudet@arctic.org>]

On Wed, 27 May 1998, Michael Anderson wrote:

> what they are - I've never seen anything like that. This may
> be a problem of "select/accept" in "multiple processes" as
> Dean described that doesn't occur in single process/multi-
> threaded accepts() sans select. Perhaps Dean can clarify?

The starvation problem is a problem with the unix API, and is still a
problem if you have multiple threads that are *concurrently* blocked in a
select()/accept() loop.  It's not a problem if they're all blocked in an
accept() loop, but that handles only a single socket.  When handling
multiple sockets, and using a wake-all primitive like select() or poll(),
you can't afford to have more than one thread enter an accept() call on a
"ready" socket.  This is because the socket is blocking, and if more than
one thread enters accept(), only one may get a socket.  This starves the
rest of the sockets...

None of this is a problem with a wake-one primitive, or if non-blocking
sockets are used (but non-blocking presents another performance
problem...). 

> the SABRE mainframe transaction system. Each request used a "clone()d"
> thread in the two middle components to process the request from
> start-to-end. So 300 simultaneous requests required 300 threads in each
> middle component.  The memory and context-switch burn of this setup was
> appalling.

This is where it's important to know what threading model is in use... if
these are all kernel-level threads, then this definately hurts really
hard.  But if they're user-level threads then context-switches are far
less expensive.  The memory burn is there either way (I'm worried about
this in threaded apache -- we have far far far too many 8k buffers on the
stack). 

The apache API is actually already positioned to allow explicit switching
at various sequence points.  In particular, everything hangs off the
request_rec structure.  The process_request_internal() function which goes
through the various stages of request processing is essentially just a
long list of sequence points.  It would be possible to break things up in
the manner you're proposing right inside this function.   Something we
should keep in mind while designing a new API...

Dean