Date: Tue, 22 Jun 1999 08:24:33 -0400 (EDT)
From: Ryan Bloom <rbb@raleigh.ibm.com>
To: new-httpd@apache.org
Subject: Re: work in progress: mpm-3.tar.gz (fwd)
In-Reply-To: <Pine.LNX.3.96dg4.990619160004.27639b-100000@twinlark.arctic.org>
Message-ID: 
 <Pine.LNX.4.04.9906220744520.21528-100000@chosondo.raleigh.ibm.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org


I have finally had a chance to review the mpm code.  I have a few
questions/concerens about it.

If the goal was to clean up http_main, I think the code should have been
split up into multiple files, not moved as one big chunk to a new file.
The sections I am thinking about are

1)  The accept_mutex logic.  This stuff is large and was already moved out
of http_main in the hybrid apache work.  Why leave it with the mpm stuff
now?  It seems to me that regardless of the mpm, we will need a method to
lock the acceptors.  Whether that be cross-process or cross-thread is 
another question, but that one is best answered with a #define or a flag
to a common function, not re-writing this section of code for each mpm.

2)  The scoreboard logic.  Again, this was moved out in the hybrid apache
work, because we wanted to make http_main smaller.  Are you saying that we
will no longer need a segment of shared memory in ALL mpm's?  I don't
believe it.  Yes, a lot of the scoreboard information is there for users
consumption only (mod_status), and the non-user information could easily
be done using other IPC mechanisms, but mod_status is incredibly useful,
and having to rebuild that information each time somebody asks for it
seems like a wasted expense.

3)  all the *_listeners functions.  ALL mpm's need some way to setup a
list of the listeners we care about.  The only method that doesn't, is one
where each socket has it's own thread listenening on it.  We discussed
moving this logic out of http_main and into our accept-loop abstraction in
the hybrid work, but decided against it, because we couldn't find a model
that didn't require this logic.

This code basically has each mpm duplicating ALOT of code, IMHO.  I will
agree that taking the child management logic out of http_main, and either
modularizing it, or just abstracting it based on platform is a good idea.

I get the feeling however, that a bunch of code was ripped out of
http_main and moved to this new mpm file, and that bothers me, because it
doesn't clean up the code, it just hides it in another file.

I believe the correct way to do this, is to follow the path we took in the
hybrid work.  Move all the code that is related to each other to separate
files, so that each mpm can use those functions easily instead of
re-inventing the wheel each time (More of this is needed in the hybrid
work).  I think if that is done, IMHO, we will find that the accept-loop
abstraction that Bill started is very close to what is needed.

:)

Just my $0.02

Ryan

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.