httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@lnd.com>
Subject RE: ap_cleanup_fn_t (was: ap_file_t typedef)
Date Tue, 04 Apr 2000 01:01:58 GMT
> From: rbb@apache.org
> Sent: Monday, April 03, 2000 5:21 PM
>
> > This would obsolete the upcoming, major patch from Bill2 --
> all those
> > APR_*_FUNC things would just go away. We would settle on
> __cdecl and be
> > done with it.
> >
> > > although as I stated in a previous note, it doen'st belong in
> > > the context it is currently being discussed for.
> >
> > True :-)  [but I'd like to see it go away altogether]
>
> Well, you;ve convinced me.  :-)  expect a patch in the next few days.

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.

<tirade>

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.

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.

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.

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.

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.

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?

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.

</tirade>

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

As for thunks, just say no :~)

Happy patching

Bill


Mime
View raw message