httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@lnd.com>
Subject RE: Windows 2.0 MPM design issues
Date Wed, 31 May 2000 17:58:40 GMT
> From: jlwpc1 [mailto:jlwpc1@earthlink.net]
> Sent: Wednesday, May 31, 2000 11:21 AM
> 
> I see I am not the only one confused. :)
> 
> Okay from the last few days mail it it _clear_ no one knows 
> just what is the Windows MPM.

I would strongly disagree with that, I'd say a majority 
understand the principals of the MPM (not specifically Win32,
but the entire Apache-wide concept.)

> So please explain to us the Windows 2.0 MPM in words (no code 
> if possible).

Fair question.  apache-2.0/htdocs/manual/new_features_2_0.html#core
is not very complete :-)  apache-2.0/htdocs/manual/misc/API.html
misses the issue entirely, apache-2.0/htdocs/manual/mpm.html is just
a pretty list, and apache-2.0/htdocs/manual/developer/modules.html
doesn't even touch it with a 10 foot pole.  So first history and
what the MPM (especially Win32) has evolved into:


It used to be we deployed just about every sort of platform
specific process, thread, parent and child logic in the main()
function of http_main.c.  It was a nightmare of tangled code,
aka. #ifdef MY_OS, #ifndef THOSE_OSES, and althought it could 
be followed, it was very ugly.

APR was to be (and still might become) the know-all, tell-all of
how to launch processes and threads on any platform, and make the
user believe it has even if they are not supported.  But that
doesn't fit into the Apache philosophy of "run this server by the 
fastest means this OS will allow".  Developers want control over 
just how the server runs on a specific OS, perhaps even to the
specific CPU.

While waiting for APR (Apache Portable Runtime) to offer all the
support, the new-httpd coders attacked http_main.c and gutted it.
What is left over is (I believe) sitting in modules/mpm/prefork.
They stripped every aspect of launching processes, establishing
the listen ports, and cleaning up afterwords into the MPM.

The MPM is the 'engine' around the server.  It's job is to create
and manage every process, thread and socket of the running server.
It is implemented as a 'module', but that's a pretty obtuse
description of what it is expected to do :-)  That's the reason
for Greg's recent posts.

Win32 was never a process-oriented engine.  The http_main.c code
did it's own threading thing (the Win32 was almost ahead of it's
time, I believe it derived first from the OS2 port.)  Bill Stoddard 
has reproduced all those funky exceptions into the winnt MPM.  You 
will find that implementation in modules/mpm/winnt/winnt.c with
both master_main() and child_main() engine loops.  


Now, when Win32 and the "Service Control Manager" came along back
in 1.3.x, the world changed.  We couldn't play our games 'inside'
of http_main.c's main() function, we needed a head start to set
up the service.  That's the #ifdef'ed apache_main() you see in
the http_main.c source.  We set up main() in main_win32.c, to do
nothing more than play with extra args and set up service control.

It's not something that other platform's won't need.  I'm betting
it's a good fit for extra args on NetWare and other non-unix
platforms.  So I created an extra hook for pre-argv processing, so
the MPM now has the following chances to set up it's OS's prefered
environment:

  register_hooks  The very first chance to set up hooks and environ.
  rewrite_args    Before the common main() touches the cmd line args

  pre_config      After cmd line args, but before we load httpd.conf
  post_config     After we've loaded httpd.conf
  ap_mpm_run      The process is ours to serve.  If the MPM returns
                  false, the config pools are cleared, all hooks are 
                  reset, and main() calls our pre-config, reloads
                  httpd.conf, calls our post_config and ap_mpm_run 
                  all over again to restart the server.


That's it.  Apache is just a function library, config processor, 
and module manager.  The gruntwork of handling processes, threads 
and the ip sockets all falls on the MPM.  That's why we will see
many different MPM's, each for a specific family of OS's, or just
a single OS, or even CPU.  Everything that is OS dependent should
be localized in the MPM, or in the APR.  The rest of the server
and modules should work (as applicable) across platforms.

Warning: you might see right here that Win9x and WinNT would make
great, seperate MPM's.  That's only 1/2 right.  Because they share
so much common code, we are asking for chances to correct bugs
on only one MPM, and forgetting the other.  So, right now, they will 
live in one MPM.

Now, since an MPM now gets a chance to hook in and diddle with the
command line args, the Win32 MPM can handle the service control
within MPM, instead of wrapping around http_main.c.

Now going back over my earlier comments on service.c, they should
make alot more sense :-)


More reading is worthwhile.  Please read Dean's master plans:

apache-2.0/src/docs/goals.txt (almost a year old, and as true as ever.)
apache-2.0/src/docs/initial-blurb.txt

There is more reading there, but I don't know how current tls.txt and 
buff.txt still are, and whatever is in new_features_2_0.html should
be moved into htdocs, CHANGES, and then knocked off.


Mime
View raw message