httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: work in progress: mpm-3.tar.gz (fwd)
Date Tue, 22 Jun 1999 18:56:56 GMT
Dude, as I mentioned in my first post, grep for the TODO comments.  I
already listed all of this. 

But my reasons for starting again with apache-1.3 go like so: 

- I know apache-1.3 works, I don't know your code works; I knew I was
  going to break everything and rather wanted to start with a code base I
  knew worked.

- I don't believe it is wise to mix the prefork and mpmt models as you
  guys did in apache-apr -- this does nothing to help with reducing the
  number of #defines; and does nothing to help people who really do have
  older unixes... my method gives them a much easier "port", they've got
  something which looks like apache-1.3 with a little more use of
  non-blocking sockets.  No other new tricks are in use.

- not everything is going to look like an fdqueue.  In Zach Brown's model
  fds are delivered via real-time queued signals -- a lightweight message
  passing protocol in essence.  Similarly in my ASH model.  Your accept
  queue stuff looked impossibly hard to integrate my code in... I tried.

- you guys made little or no attempt to abstract and define the
  method/ordering of configuring the server; in my opinion we can't even
  begin to talk about different mpms without specifying the order in which
  modules will be invoked during configuration and run-time.  Module
  authors need to know their execution environment.

- I wanted to lay the groundwork for abstracting the protocol from the
  MPM.  It's a simple change to MPM now to call (*protocol_handler)()
  instead of ap_process_connection.  (This is required for folks wanting
  to play with the transport layer... such as mux and ssl.)

- The scoreboard can't just be hidden in another file, it needs a complete
  redesign.  I decided to just lose the functionality for now until we can
  figure out all the pieces needed to put it back together.

In short, I tried to work with your apache-apr/pthreads code for the ASH
stuff I was doing.  I couldn't.  This is why I stepped back and tried to
figure out why, and that's what resulted in the MPM code. 

There's nothing stopping you guys from taking the apache-apr/pthreads
stuff and bringing it over to the MPM model -- all the hooks are there...
and it's totally welcome!  And it looks like manoj has done that :) 

In short, I don't think we've lost anything.  Every one of these attempts
-- RST's age old threaded work; my first pthread port; my NSPR port; the
manoj/ryan pthread port -- has taught us something.  You guys in
particular gave me much more insight into the gnarly problems of
restart/shutdown.  MPM is just my view on how it all fits together. 

I look forward to all the abstractions you list, because I'll need those
pieces as well for my work.  You can see I started -- with splitting out
the "unix daemon" code -- the detach/uid/gid stuff.  Yup Listen needs to
happen soon.  Ralf's MM stuff should go in to satisfy the unix
multiprocess shared mem/semaphore needs.

At that point mpm_prefork will amount to a dynamic process pool management
module... and hey maybe even that might want to be abstracted.  But I'm
not sure I need it -- my model will have a fixed number of processes; and
I don't want any signals used.  But as I said back up there, I want
mpm_prefork as close to apache-1.3 as possible because then we have
something we know works (and that should keep the non-modern unix folks
appeased :) 

I also had another big goal -- I wanted to show a roadmap which has lots
of open projects still left in it... so that we can take advantage of some
parallel development.  So yup, MPM lacks all the stuff you mentioned... 
for a good reason... it was a design which we've been solidifying over an
18 month period and then I spent a day or so hacking to lay out the
framework... and if I've convinced everyone it's going in the right
direction multiple of us can spend time polishing up the rough edges.

Yeah ok I'm procrastinating from cleaning up the mess I've made of buff.c.

Dean

On Tue, 22 Jun 1999, Ryan Bloom wrote: 

> 
> 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.	
> 
> 
> 


Mime
View raw message