httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject RE: ap_cleanup_fn_t
Date Tue, 04 Apr 2000 02:32:02 GMT
On Mon, 3 Apr 2000, William A. Rowe, Jr. wrote:
> To the point of APR_THREAD_FUNC (most Win32 folks expect _PROC, but that's
> another issue), I agree that APR_THREAD_FUNC isn't APR_CALLBACK_FUNC.  Now
> around the point...
> Just a quick and slightly argumentitive question, but have you ever gotten
> mod_info working under NT?  Didn't think so.

I visited Covalent last week, and spoke with Ryan, Daniel, and Doug about
configuration stuff and ways to leverage those changes into a working
mod_info. Sure, it doesn't work today, but it will work fine in 2.0.

> <tirade>

Uh oh :-)

My apologies for getting you to this state. Please consider this message a
discussion, rather than a knock against your efforts...

> Clearly, we aren't looking at the bottom lines here.  I like simplicity too
> and don't like tons of wrappers over things that don't need wrappers.  I
> like compiler switches as well, as evidenced by my /Define proposals.

Agreed on the first, ambivalent on the second.

> One, external data requires linkage pragmas to resolve to foreign DLL's
> data.  If you don't believe me, show me a working 1.3.x external mod_info
> module.

No doubts there. Your efforts to correct the data linkage are hugely
important, and I don't think we are discussing those guys. All that stuff
should go in. The issue, of course, is that Bill (Stoddard) is probably a
bit backed up on reviewing those patches (and sorting through your monster
patches :-)

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

> Three, all Apache modules are written in C.  Sure, -our- modules will be
> written in C, but we can forsee others extending Apache in other languages.
> cdecl is exactly that, C's convention.  The rest of the world lives and
> breaths stdcall, except in varargs that aren't even supported as such.

I believe all modern programming languages (which create binaries), such
as <foo> Pascal and VB, can generate cdecl code. If somebody needs to
insert __stdcall or __cdecl somewhere, can't it be the few who choose to
use these other tools? (rather than the majority who use C/C++?)

> Four, we will always build a flexible Apache in stdcall.  If one is not
> using third party modules or extending it in other langauges, then toggling
> cdecl does make sense.

If we want all of Apache to be built using stdcall, then can't we just
flip the default call model on the compiler line? Can't we avoid the
insertion of call-model macros for all API functions?

> Five, that the client module is written to the same calling convention as
> APR and ApacheCore.  Sure, our own DLL's will (probably) share the same
> convention.  But are you willing to declare that all must compile their
> modules to the Apache convention, when wrappers could have told the client
> exactly how to call us, regardless of their -own- compilation switches?

Hrm. I'm having a hard time parsing through this.

One item of background: as it stands today, all modules must be built with
the same set of switches as Apache.

If we want to allow modules to be built using different models or switches
or whatever, then some kind of wrapper/thunk will be necessary to map
between the module's code style and Apache's export code style.

I'm unsure of what "wrappers" you're referring to. Are these wrappers that
we supply or ones that the module develop supplies?

> I really foresaw Apache 2.0 offering additional flexibility while buying
> optimizations that would increase our market appeal, not shrink them down to
> a single inflexible configuration.  I think that was already done quite
> admirably (no sarcasm or derision here) in httpd.  That vision for Apache
> 2.0 is certainly of no interest to me.

I understand and agree with your general sentiment. However, I am not sure
what we buy if we have the ability to easily flip between calling
conventions. As I see it, we have:

*) pro: no call-convention macro means we never accidentally omit it
*) pro: no macro keeps the source "lighter"
*) con: module developers using languages that cannot generate cdecl code
        must work harder

Hmm. It would be nice to have a longer list there :-)

I think one point that I'd like to mention is simply: providing Yet
Another Way To Compile Apache means that we introduce more complexity into
the config/build process (to support the increased flexibility). If that
additional flexibility does not buy us a whole lot, then I'm in favor of
trading it out for the resulting simplicity.

> The -original- problem to resolve is in fixups.  Get rid of them.

Which fixups are these? The fact that we don't have ordinals in the .def
file, or the linkage for the data?

> As for thunks, just say no :~)

Note that I'm not referring to Win16 thunks :-). Gawd, you're right on
that part... just say no.  No, I mean a simple routine such as:

struct start_thread_data {
  ap_thread_start_t func;
  void *data;
unsigned int __stdcall thunk(void *ctx)
    struct start_thread_data *std = ctx;

    /* ### what to do with the return value? */
    (void) (*ctx->func)(data);

    return 0;  /* ### what does Windows want here? */

ap_status_t ap_create_thread(...)
    struct start_thread_data std = { func, data };

    ... _beginthreadex(NULL, 0, thunk, &std, 0, &temp) ...


This eliminates the nasty casting in ap_create_thread's use of
_beginthreadex(), and it means the thread functions don't have to declare
a special calling convention.


Greg Stein,

View raw message