httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: cvs commit: apache-2.0/src/lib/apr/include apr.hw apr_config.hw
Date Wed, 05 Apr 2000 16:08:18 GMT

> However, MPM's (which are platform specific) reinvent
> this functionality today.  I realize more and more of
> MPM will leverage the APR, but it will yet and still
> need to make decisions based on the platform.  (Why
> else would we invent multiple MPM's?)  We've already
> kicked around the thought of 2 MPM's, NT and 9x.  So,
> consider the MPM case before you set the final 
> decision in stone.  (As I said, I'm happy to keep it
> internal today, alpha's are more mudflows than stone :~)

MPM's should IMHO be one of two types.  1)  Portable using APR.  2)  Not
portable, platform specific.  

If they are type 1 (like prefork should be), then knowing which platform
they are on is not necessary.  All decisions should be based on features,
not platforms.

If they are of type 2 (WinNt, 9x), then all decisions should be made by
the configuration, or at run time by calling the function and checking for
APR_ENOTIMPL.  I really don't care if Win9X has to make a couple of extra
function calls every now and then.  I think any platform that is viable as
a server platform will implement either 99% - 100% of the APR functions,
or they will have their own MPM.  Currently the only MPM that is
duplicating this knowledge is the Win32 MPM, and it could just as easily
use a small heuristic than export this function.  

For example, we know that Win9X doesn't support named pipes (I think
that's right).  If we need to know which platform we are on, at the
beginning of the Win32 MPM, we could call ap_create_named_pipe and check
the return code.  If it is APR_ENOTIMPL we are on 9x otherwise we are on

I am just a HUGE fan of making decisions based on features not platform
level.  :-)


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message