httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Magnuson <>
Subject Re: hooks
Date Wed, 21 Jun 2000 01:15:47 GMT writes:

> I believe you are missing something.  :-)  I assume you are talking now
> about a module that wants to provide hooks for other modules to register
> for.
> The AP_IMPLEMENT_HOOK is a macro, and it will never need to be exposed
> through a .def or .exp file.  The symbol that is exposed is the generated
> symbol.  This means, for example, that ap_hook_check_user_id is exposed,
> but not AP_IMPLEMENT_HOOK  (which is the macro that generates the
> ap_hook_check_user_id function).
> AP_HOOK_STRUCT is also not exposed, because it is a static variable.  It
> took me a long time to see how this all fits together, but here it goes:
> when you declare AP_HOOK_STRUCT at the top of a file, that defines:
> static struct {
>     ap_array_header_t link_(first_hook_name)
>     ap_array_header_t link_(second_hook_name)
>     ap_array_header_t link_(nth_hook_name)
> }
> Then, at the bottom of the file you use the AP_IMPLEMENT_HOOK_* macros to
> actually generate the relevant functions.  There are two functions
> generated.  The first basically add a function pointer to the hook, and
> the second loops through the hook calling the functions.  The first is
> ap_hook_(hook_name) and the second is ap_run_(hook_name).  The first is
> public and needs to be put into the .def or .exp file, but the second is
> static and should not be exposed.

Sorry for confusion, when I said it needs to include AP_* I really meant the
stuff generated BY the AP_* macros :)

Anyway.. you are right the ap_run_(hook_name) symbol must be exported so
that the module can call it however..... ap_run_* uses _hooks, _hooks comes
from AP_HOOK_STRUCT, which is static, which isn't exported to the module, I
guess this is where my confusion comes from. I am very probably wrong - or
misunderstand something about windows (or AIX) linker, but I certainly
thought this was a no-no.

> The final piece to all of this is the AP_DECLARE_HOOK that goes into the
> header file.  This just declares a couple of prototypes, and sets up the
> LINK_(hook_name) structure to be used for inserting new hooks.
> This should explain how things are shared or not shared in a relatively
> straight forward manner.  Please if this doesn't help, let me know.  Ben,
> if I have this completely wrong, please correct me.

This does help, I have a doc sitting around from a gcc -E of one of these
just so I can refer to it when I get lost in the macro evilness :)

> > Yes the programmer needs to decide where it needs to be hooked, but since
> > we're using hooks instead of single function pointers, one can assume how
> > the call is directed to be transparent. 
> It would really help me out if you could give an example of what you are
> thinking here.  I am having a VERY hard time parsing this.

I apologize, I will clarify below (1)..

> > But this hooking mechanism seems to be less than useful when modules want
> > to create hooks for other modules. I guess what I'm wondering is why it has
> > changed so significantly from 1.3?
> If a module creates a hook for other modules, then this implies that the
> first module is always in the server.  This is just not the case with
> Apache, and we do not code for that case.  For example, say mod_foo
> implements a hook and mod_bar registers a function for it.  if mod_foo is
> not in the server, then mod_bar has no place to be registered.  This is a
> bad thing.
> It has changed so siginificantly from 1.3, because in 2.0 we didn't want
> the order of the hooks to be dependant on the module.  The hooks needed to
> be independant of each other.

This is definetly a good goal, however adding to the hooking that was in
1.3 so it had order fu in the API might have been a good thing, if for no
other reason to ease migration from 1.3. As is obvious I've come along (to
hacking on apache) late in the 2.0 time - so I may be missing key
discussions, I will go to an archive and start perusing, but it seems the
old API had some very good features (minus the ordering troubles)..

> > Yes I guess I mean the latter, if a module came along and wanted to reuse a
> > hook for something "similar" to what the hook was originally for - I'm not
> > sure why that would be a bad thing, worse is having each module that
> > supports foobar needs to have ap_hook_this_foobar and ap_hook_that_foobar
> > to get itself to work right..
> First of all, because the _hooks struct (declared by AP_HOOK_STRUCT) is a
> static, I take it back.  It is not possible to share a hook between two
> modules.


> But why are multiple modules supporting foobar?  If your module needs the
> same function that the core implements, don't duplicate the core's work,
> take advantage of it.  Throw your function in as a REALLY_LAST function
> and use what the other modules have already done.

I'm sorry - what I was referring to was suppose there was a foobar hook
(ap_hook_foobar) and it is used by the core, then I write a module and I
want to go behind the core's back (for some reason) and trigger a foobar
(ap_run_foobar) too, to do this I would either

a) have to hack up something (as you said big hack above) to do this, but
   supposedly it's "bad"
b) have a new hook, and any module that wants to do foobar for my protocol,
   or http would have to know about both and be sure to hook both.

I'm looking at it more from a standpoint of "Why are we limiting it in this
way?", it is also reasonable to decide these limitations are acceptable -
the original questions where asked while I was still in throught process,
explanation below (1)...

> What this really comes down to, is we need a real-world example of what
> you are trying to do before we can even hope to help.  My problem is that
> I don't really see what you are trying.  William Wrowe just responded
> saying that a patch to allow some of what you are trying was shot
> down.  It was shot down because nobody saw the need.
> Apache takes a very hard line against just including function for the sake
> of including function.  If there is a real need for an ability (the
> ability to have a module declare it's own hooks, for example), the group
> is perfectly willing to help implement it.  If it is just something that
> sounds like it could be useful, then we don't in general implement
> it.  Give a real-world example of what you want, and we can and will work
> with you to make it happen.

(1) Ok real world has to do with....

I was doing some thinking about protocol modules. I was thinking the http
stuff could be split into a separate module, and we can have a generic
server framework (as most of the work is really there and this would just
be tying up loose ends). I was thinking about the next protocol modules
that might come along, and thought there were a bunch of useful modules for
the http side of things, perhaps new protocol will have a use for
them. Then it started to occur to me the hooking mechanisms probably aren't
going to be sufficient for inter-module hook relay, to boot it wouldn't
really provide new protocols with a way to use hooks that exist for http

All of this is fine if the abstraction of protocols is to give an easy way
of plugging in an all new monolithic module that incorporates all the stuff
for another protocol (ala the apache core stuff). If it is there to provide
the ability to have a very generic framework and I can easily plug in
different protocols and those different protocol modules can use some
common modules to do certain aspects then it seems what exists isn't going
to work well.

I understand 2.0 might not have all that in it, but since 2.0 is new enough
not to have all modules ported to it, I figured it may be worthwhile coming
up with something (the more I look at it the more the 1.3 hooking facility
seems to be it) to correct these hooking issues.


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

Sam Magnuson <>

View raw message