httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject RE: cvs commit: apache-2.0/src/modules/mpm/winnt winnt.c
Date Sat, 27 May 2000 22:11:21 GMT
On Sat, 27 May 2000, William A. Rowe, Jr. wrote:
> > From: Greg Stein [mailto:gstein@lyra.org]
> > Sent: Saturday, May 27, 2000 4:07 PM
>...
> > 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.

ap_pre_config_hook could be a candidate because actual modules may want to
use that. There used to be some kind of issue with loading. Dunno if that
has truly been fixed, but Ryan has indicated that pre_config should go
back in [for modules to use]

If pre_config only makes sense for MPMs, then I'm against using a hook.

process_args should NOT be a hook either.

The semantics behind a hook are "if there is anybody out there, then
please respond." The slots in the module_rec have the semantic "hey YOU:
please handle this if you want."

Hooks are a broadcast mechanism, entry slots are directed.

process_args is *directed* to the MPM that is being used. It is NOT a
broadcast, so it should not be implemented as such.

create_dir_config, merge_dir_config, handlers, commands, etc (used by
modules) are also "directed" and (thusly) they remain slots rather than
hooks.

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

Why? MPMs don't use things like "create_dir_config" or "handlers".

Yes, there is a common header, but the structures are more like this:

struct common_module_rec {
  magic number, module handle, other goop
}

struct module_rec {
  common_module_rec;
  ...
  create_dir_config
  ...
}

struct mpm_rec {
  common_module_rec;
  ...
  process_args;
  pre_config_hook;
  ...
}

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

:-)  Now we just need "the others" to state WHY it shouldn't happen this
way. Majority (so far :-) says it should.

hehe...

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/


Mime
View raw message