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: pre_config and rewrite_args hook or struct member?
Date Sat, 27 May 2000 22:23:43 GMT
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Saturday, May 27, 2000 5:11 PM
> 
> 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.

Why?  It's a global pointer structure that NULLs out if the platform
isn't interested in the hook.  

We setup the hooks prior to walking either hook, and I'm not certain
it makes any difference.

> process_args should NOT be a hook either.

Same argument

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

Is that the definition of the hook?  If so you are correct.
If we implemented hooks to get rid of the growing nightmare of
pointers in the module structure, then I entirely disagree with
using pointers.

And you are assuming we aren't running dual MPM's, one for the server,
one for the dedicate network coprocessor :-)

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

Yes it should, if we are trying to shrink the laundry list of unused
feature hooks from the module structure.  Are we?

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

If that is the why, then I totally concur with your position.

> >...
> > > 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
> }
 
Fine.  I could accept that.



Mime
View raw message