httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject Re: Duplicate code.
Date Fri, 19 Nov 1999 19:44:18 GMT
On Fri, Nov 19, 1999 at 10:16:33AM -0500, Ryan Bloom wrote:
> The scoreboard and accept locking code seem to be the biggest offenders,

Ummm, as of Monday, the accept lock code is based on APR for the two
threaded Unix MPMs. Prefork still needs work, but that shouldn't be
too difficult.

You're seeing duplicate messages, because that's what you're working
on, but that's really the only significant accept lock piece
duplicated between mpmt_pthread and dexter. I don't think it's worth
the effort to create a common ap_lock_with_error_report call.

And besides, I'm hoping to take cross-process locking out of dexter
completely by taking advantage of non-blocking accept.

The scoreboard code is somewhat duplicated, but it's doing somewhat
different things in the various Unix MPMs. In prefork and
mpmt_pthread, it contains all the old-style scoreboard code. Dexter
doesn't use the old-style scoreboard at all, so it just has generic
code to create a block of shared memory, and another chunk of code to
use it to maintain connection status. I think it would be useful to do
a similar split of the scoreboard code in the other MPMs, but the
proper way to do this is to get shared memory code into APR.

> The idea itself is wonderful, but our execution has MPM's implementing all
> of the helper functions that used to be common code.  Why can't MPM's just
> be responsible for spawning threads and creating processes, and mapping
> requests to those execution primitives it sees fit.  Anything else is
> superflous, and most likely common to at least two MPM's.

The Unix MPMs already have piles of common code, see unixd. Sure, more
stuff could be moved, but the low hanging fruit has been picked

And MPMs will soon have to manage event-based I/O at some point too.
Manoj Kasichainula - manojk at io dot com -

View raw message