httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <stodd...@raleigh.ibm.com>
Subject Re: ap_cleanup_fn_t
Date Tue, 04 Apr 2000 15:01:38 GMT
>
> > Two, you are eating plenty of extra clock cycles by not forwarning the
> > ApacheCore that the functions reside in a DLL.  The linker is writing
plenty
> > of fixup thunks for you.
>
> Hrm. How is this forewarning occurring? I haven't seen this.
>
> Definitely, we can improve speed by using numbers in the .def files, but
> what else is needed?
>

Take a look at how API_EXPORT (et. al) are implemented in Apache 1.3. On
Windows, the API_* macros identify functions and variables as being either
imported into or exported from (dllimport, dllexport) the DLL.  The
definition of API_EXPORT (dllimport or dllexport) depends on if
SHARED_MODULE is defined or not. SHARED_MODULE is defined for dynamically
loaded modules but not for ApacheCore. From the dynamically loaded modules
perspective, all the functions in ApacheCore wrappered with API_EXPORT are
identified as needing to be imported (dllimport), which eliminates a thunk
when the DLL calls an ApacheCore function.  It get even wierder if the
module needs to access an ApacheCore extern variable. If the variable is not
wrappered correctly, you need to explicitly handle the pointer indirection
to get at it.  (See the Windows dll linkage warnings on ap_opt* variables in
APR. It's just blind luck it works at all the way it is)

The SHARED_MODULE technique worked pretty well in Apache 1.3 because there
are only two DLLs interacting with each other at a time, ApacheCore and the
DSO module.  Apache 2.0 throws APR into the mix which means Apache and APR
need to have different wrappers (I think). If we statically link APR, then
we can continue to use the SHARED_MODULE technique.  It works the way it is
but we do chew up CPU thunking each call to APR. Not sure how significant it
is though.

Bill


Mime
View raw message