On Sat, Oct 24, 1998, [EMAIL PROTECTED] wrote:
> > Four additional module hooks, a generic low-level hook mechanism and a
> generic
> > context mechanism. All three thing together provide a way to _loosely_
> couple
> > mod_ssl into the Apache core code instead of couple it via direct symbol
> > references (the big NO-NO for DSO). This way even inter-module
> communication
> > is possible: For instance mod_log_config's SSL support is now loosly
> coupled
> > to mod_ssl, too. This way mod_log_config has not even to be linked
> against
> > SSLeay ;-)
>
> There are two things I'm curious about:
>
> First, do you have any kind of performance penalty figures? Not
> that my Net connection could in any way saturate my apache on my
> <insert fast processor here> box, but I'd be interested nonetheless.
You mean performance penalty because of PIC code inside the DSO?
No, but experience with DSO in general showed what I wrote
down in the dso.html file of Apache:
- The server is approximately 20% slower at startup time because of the symbol
resolving overhead the Unix loader now has to do.
- The server is approximately 5% slower at execution time under some platforms
because position independent code (PIC) sometimes needs complicated
assembler tricks for relative addressing which are not necessarily as fast
as absolute addressing.
But it depends on the platform or especially on the CPU type. But when I take
Dean G.'s statements about performance into account (he says AFAIK that the
main performance problem is I/O inside Apache and not code loops, etc.) the
PIC penalty should be harmless. At least I've never observed any _noticeable_
performance lacks on my webservers because of DSO. And I have all modules
DSOs...
> The second thing: are your patches to the core code folded back
> into the main apache code? I understand that the apache group did
> not want cryptography code in the main code base, but if your patches
> only add "generic hook mechanisms", there could be a chance that we
> wouldn't need the apache.patch with 1.3.4 or 2.0 ;-)
As I said in another reply on this thread: IMHO the _implementation_ of the
hook _mechanism_ can be folded back into Apache as long as we don't fold back
also the hook _calls_ (the actual _hooks_!). Because even when they are
generic hooks they are considered crypto hooks because they were generated for
this purpose. But folding back the new generic and reuseable code inside
src/ap/ap_hook.c and src/ap/ap_ctx.c I wrote can be included into Apache.
Because these are not hooks itself. But this code can be used by module
authors to loosely couple modules for inter-module communication. And it the
ap_ctx stuff solved one problem we already have Apache-PRs for: Buffer or
Connection context information for modules.
I'll talk to the other Apache developers on this topic after mod_ssl 2.1b7 is
out with the code. Then they can have a look at the generic code inside
src/ap/ap_hook.c and src/ap/ap_ctx.c and perhaps we can include this into
Apache. We'll see...
Greetings,
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
