From: "Greg Ames" <[EMAIL PROTECTED]> Sent: Thursday, December 13, 2001 12:49 PM
> "William A. Rowe, Jr." wrote: > > > . Hooks are _not_ the fastest things in the world, especially with the strcmps > > around ->handler going on. > > Amen! This one has been bugging me for a long time. It won't show up > clearly in a profiler, because the CPU cycles are spread over all the > handlers. We are polluting the instruction cache by touching a lot of > separate chunks of code that only return DECLINED. > > > If we resolve the ->handler up front, why not > > provide a ->handler_fn member that skips the entire handler() hook walk? > > The implementation would be interesting. Consider mod_dir and > mod_autoindex. Both can deal with DIR_MAGIC_TYPE, and both could be > present or absent. But when both are present, the handler topological > sort rules must be respected so that handle_dir runs first. How do you > propose dealing with that? And what about the few handlers that support > fuzzy matches? Couple of bits. If we declare handler_fn identically to a hook_handler callback, then we can maintain the semantics. A handler could raise it's hand, but later DECLINE. If it DECLINEs, or handler_fn is NULL, then we proceed with the usual walk. Second, autoindex should be a generator [handler]. mod_dir should _NOT_. I spelled out the reasons for that on 2001.12.02. It is part of the wide bogosity of dir requests 'slipping through' into autoindex. mod_dir could only be considered a handler if it returns an external redirect, any other response it provides in an internal fixup that should happen in fixups. If you try my mod_dir/autoindex patches of late 2001.12.02 [when I got around to fixing the implications of mod_dir as a fixup in mod_autoindex] you should discover it runs fine. Had changed mod_dir it to use our ap_fast_internal_redirect, so it will uncover more bugs than mod_negotation does alone. Bill
