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: cvs commit: apache-2.0/src/modules/mpm/winnt winnt.c
Date Sat, 27 May 2000 21:45:03 GMT
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Saturday, May 27, 2000 4:07 PM
> 
> On Fri, 26 May 2000 rbb@covalent.net wrote:
> > On 27 May 2000 wrowe@locus.apache.org wrote:
> > > wrowe       00/05/26 23:22:56
> > > 
> > >   Modified:    src/main http_main.c
> > >                src/include http_config.h
> > >                src/modules/mpm/dexter dexter.c
> > >                src/modules/mpm/mpmt_beos mpmt_beos.c
> > >                src/modules/mpm/mpmt_pthread mpmt_pthread.c
> > >                src/modules/mpm/prefork prefork.c
> > >                src/modules/mpm/spmt_os2 spmt_os2.c
> > >                src/modules/mpm/winnt winnt.c
> > >   Log:
> > >   
> > >     Pass the process_rec to the MPM to allow rewriting of 
> the args list.
> > >     Especially necessary under Win32, or other non-unix 
> front ends where
> > >     oddball arguments might be required, but without 
> causing a mess in
> > >     http_main.c.
> > 
> > I dislike this.  You posted last week that you wanted to do 
> this, and you
> > received back comments asking why this was necessary.  
> After a thorough
> > discusssion on new-httpd, it sure sounded like the patch was being
> > re-written.  Now, the original change has been made.
> 
> No, this patch is quite different. Originally, OtherBill was 
> going to pass
> the process_rec to register_hooks(). That was Badness(tm).

Greg hit this on the head... the hook has the express permission to
modify the process_rec, especially it's argv[].  No dual-use of the
module setup phase.

> However, I had thought that a new HOOK would be written, 
> rather than an entry in the module_rec (for MPMs only).
> I don't understand why it is an entry rather than a hook. 

For One (1) Reason Only: ap_pre_config_hook is certainly a candiate
as well.  My supposition was that we didn't want to rely on the hooks
being all set to fly, might be late binding, or whatever.

If I'm wrong, and this should be an AP_HOOK, then I gather they should
both become AP_HOOKs.  If this is so, I'll even code and commit.

> ESPECIALLY given that none of the MPMs are implementing that entry.

Hmm... I'm waiting for the other platform writers (read: "NW") to
notice this hook and strategy.  I'm most certain it has other
consumers.

> Hmm. <stream-of-consciousness-kicks-in> ...
> 
> The module_rec entry makes sense. There is only ONE MPM every loaded.
> There is no reason to use the hook system to call features of the MPM.
> 
> Given the increasing difference between module_rec for modules and
> module_rec for MPMs, it probably makes a LOT of sense to simply break
> these apart and use two definitions.

The only way I can buy this is if mpm_rec is defined in terms of

struct mpm_rec
{
  struct module_rec module;
  [mpm_args]
}

> > I personally would have liked to have seen this patch before 
> > it was committed.  I am still
> > not sure that I like passing the process_req around.
> 
> Why is passing it bad? The MPM needs it to process arguments. And MPMs
> really must be able to do that.

I'm arguing the same.  The MPM -is- the platform specific hub for
execution.  It really is co-owner of the entire process scheme.

> > I definately do NOT like adding another function to the 
> > module table.
> 
> For MPMs, this makes a lot of sense. For modules, I agree with you.

See my comment above, I'd drop them both rewrite_args and pre_config
out as ap_hooks.

> > I am currently -0.5 for this patch, but I need to review it 
> > in much more detail.

Fair... I'm waiting.  No more xplat commits for a (long?) while here.

Mime
View raw message