You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by rb...@covalent.net on 2000/07/07 19:09:30 UTC
Unix MPMs...
I spent all day yesterday combining the Unix MPMS. I would like to commit
my new MPM, called mpmt. With my current changes, this one MPM can
emulate dexter, mpmt_pthread, and prefork. With a SMALL bit of work, it
can probably also be used for the os/2 and beos MPMs.
There are currently 40 places in the entire directory where I check for
which MPM is currently being used. Many of those can go away once we
finish the scoreboard abstraction, and if we invest some time in scrubbing
the code. There are two or three functions that are just re-implemented
wholesale for each MPM.
I would really like to commit this new MPM, called mpmt. Any objections?
There will be bugs with the new MPM, but it merges a lot of common code,
and give us less room to miss bug fixes in the future. Plus, it doesn't
hurt that it reduces the size of the tree a bit.
My current thought is to commit the new MPM, along with the new config
stuff. The new config stuff keeps the old MPMs from being
compiled. Then, after a day or two we can remove the old MPMs.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Unix MPMs...
Posted by David Reid <dr...@jetnet.co.uk>.
Anything to keep my workload down... :)
----- Original Message -----
From: <rb...@covalent.net>
To: <ne...@apache.org>
Sent: Saturday, July 08, 2000 5:09 PM
Subject: Re: Unix MPMs...
> On Sat, 8 Jul 2000, David Reid wrote:
>
> > I'll have a look at the code for beos in a couple of days, once things
have
> > settled a little. At a minimum the pthread calls need to go away, and
> > forking isn't an option either. I agree with Brian that a set of
mpm_common
> > code would be useful.
>
> You may want to wait a week. That MPM is going to be changing A LOT in
> the next week or so.
>
> Ryan
>
>
> >
> > david
> >
> > >
> > > I spent all day yesterday combining the Unix MPMS. I would like to
commit
> > > my new MPM, called mpmt. With my current changes, this one MPM can
> > > emulate dexter, mpmt_pthread, and prefork. With a SMALL bit of work,
it
> > > can probably also be used for the os/2 and beos MPMs.
> > >
> > > There are currently 40 places in the entire directory where I check
for
> > > which MPM is currently being used. Many of those can go away once we
> > > finish the scoreboard abstraction, and if we invest some time in
scrubbing
> > > the code. There are two or three functions that are just
re-implemented
> > > wholesale for each MPM.
> > >
> > > I would really like to commit this new MPM, called mpmt. Any
objections?
> > > There will be bugs with the new MPM, but it merges a lot of common
code,
> > > and give us less room to miss bug fixes in the future. Plus, it
doesn't
> > > hurt that it reduces the size of the tree a bit.
> > >
> > > My current thought is to commit the new MPM, along with the new config
> > > stuff. The new config stuff keeps the old MPMs from being
> > > compiled. Then, after a day or two we can remove the old MPMs.
> > >
> > > Ryan
> > >
> > >
> > >
> >
____________________________________________________________________________
> > ___
> > > Ryan Bloom rbb@apache.org
> > > 406 29th St.
> > > San Francisco, CA 94131
> >
> --------------------------------------------------------------------------
> > -----
> > >
> > >
> >
>
>
>
____________________________________________________________________________
___
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> --------------------------------------------------------------------------
-----
>
>
Re: Unix MPMs...
Posted by rb...@covalent.net.
On Sat, 8 Jul 2000, David Reid wrote:
> I'll have a look at the code for beos in a couple of days, once things have
> settled a little. At a minimum the pthread calls need to go away, and
> forking isn't an option either. I agree with Brian that a set of mpm_common
> code would be useful.
You may want to wait a week. That MPM is going to be changing A LOT in
the next week or so.
Ryan
>
> david
>
> >
> > I spent all day yesterday combining the Unix MPMS. I would like to commit
> > my new MPM, called mpmt. With my current changes, this one MPM can
> > emulate dexter, mpmt_pthread, and prefork. With a SMALL bit of work, it
> > can probably also be used for the os/2 and beos MPMs.
> >
> > There are currently 40 places in the entire directory where I check for
> > which MPM is currently being used. Many of those can go away once we
> > finish the scoreboard abstraction, and if we invest some time in scrubbing
> > the code. There are two or three functions that are just re-implemented
> > wholesale for each MPM.
> >
> > I would really like to commit this new MPM, called mpmt. Any objections?
> > There will be bugs with the new MPM, but it merges a lot of common code,
> > and give us less room to miss bug fixes in the future. Plus, it doesn't
> > hurt that it reduces the size of the tree a bit.
> >
> > My current thought is to commit the new MPM, along with the new config
> > stuff. The new config stuff keeps the old MPMs from being
> > compiled. Then, after a day or two we can remove the old MPMs.
> >
> > Ryan
> >
> >
> >
> ____________________________________________________________________________
> ___
> > Ryan Bloom rbb@apache.org
> > 406 29th St.
> > San Francisco, CA 94131
> > --------------------------------------------------------------------------
> -----
> >
> >
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Unix MPMs...
Posted by David Reid <dr...@jetnet.co.uk>.
I'll have a look at the code for beos in a couple of days, once things have
settled a little. At a minimum the pthread calls need to go away, and
forking isn't an option either. I agree with Brian that a set of mpm_common
code would be useful.
david
>
> I spent all day yesterday combining the Unix MPMS. I would like to commit
> my new MPM, called mpmt. With my current changes, this one MPM can
> emulate dexter, mpmt_pthread, and prefork. With a SMALL bit of work, it
> can probably also be used for the os/2 and beos MPMs.
>
> There are currently 40 places in the entire directory where I check for
> which MPM is currently being used. Many of those can go away once we
> finish the scoreboard abstraction, and if we invest some time in scrubbing
> the code. There are two or three functions that are just re-implemented
> wholesale for each MPM.
>
> I would really like to commit this new MPM, called mpmt. Any objections?
> There will be bugs with the new MPM, but it merges a lot of common code,
> and give us less room to miss bug fixes in the future. Plus, it doesn't
> hurt that it reduces the size of the tree a bit.
>
> My current thought is to commit the new MPM, along with the new config
> stuff. The new config stuff keeps the old MPMs from being
> compiled. Then, after a day or two we can remove the old MPMs.
>
> Ryan
>
>
>
____________________________________________________________________________
___
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> --------------------------------------------------------------------------
-----
>
>
Re: Unix MPMs...
Posted by rb...@covalent.net.
> I've had a browse through the code & I'm afraid it will take a fair bit of
> work to make it run on OS/2.
I know it'll take some work. Give it a week or so and look again. :-)
>
> - It's full of pthread calls.
These all need to change anyway. Expect these to become APR thread calls
soon-ish
> - I don't think the 'pipe of death' concept is going to work as a file/pipe
> handle can't be select()ed on.
> - It fork()s (although it works on OS/2 it's extremely inefficient because
> it's emulated).
Those I can't help
>
> Trying to unify the different variations of unix MPMs may be of benefit. I
> don't think trying to jam in the OS/2 or Win32 MPMs is a good idea, they're
> just too different (not too sure about BeOS). Pulling out as much common
> code as possible into mpm_common would be more useful.
I plan to pull out a lot of the common code to mpm_common.c as well. I
wasn't sure if it would be possible to add OS/2 or not. Good to see your
opinion. I won't try.
> BTW, there's some really screwy formatting in your commit. It looks like
> some lines have been joined accidentally. EG mpmt.c:769
This happens occasionally. I still don't know why. I tried to find/fix
them all, but I missed a few. I'll try to fix them.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Unix MPMs...
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Fri, 7 Jul 2000 10:09:30 -0700 (PDT), rbb@covalent.net wrote:
>I spent all day yesterday combining the Unix MPMS. I would like to commit
>my new MPM, called mpmt. With my current changes, this one MPM can
>emulate dexter, mpmt_pthread, and prefork. With a SMALL bit of work, it
>can probably also be used for the os/2 and beos MPMs.
I've had a browse through the code & I'm afraid it will take a fair bit of
work to make it run on OS/2.
- It's full of pthread calls.
- I don't think the 'pipe of death' concept is going to work as a file/pipe
handle can't be select()ed on.
- It fork()s (although it works on OS/2 it's extremely inefficient because
it's emulated).
Trying to unify the different variations of unix MPMs may be of benefit. I
don't think trying to jam in the OS/2 or Win32 MPMs is a good idea, they're
just too different (not too sure about BeOS). Pulling out as much common
code as possible into mpm_common would be more useful.
BTW, there's some really screwy formatting in your commit. It looks like
some lines have been joined accidentally. EG mpmt.c:769
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------