Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
From: "William A. Rowe, Jr." <wrowe@lnd.com>
To: <new-httpd@apache.org>
Subject: RE: linkage mechanisms
Date: Thu, 23 Mar 2000 09:08:11 -0600
Message-ID: <000001bf94e2$d4ffb1f0$345985d0@corecomm.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-reply-to: <Pine.LNX.4.10.10003230335170.27878-100000@nebula.lyra.org>
Importance: Normal

> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Thursday, March 23, 2000 5:41 AM
>
> On Thu, 23 Mar 2000, William A. Rowe, Jr. wrote:
> >...
> > I've rewritten the DECLARE_HOOK/IMPLEMENT_HOOK macros' args
> > to take the calling model (_EXPORT_FUNC) and linkage
> > (_EXPORT or _EXPORT_NONSTD) for any specific library's hooks.
>
> Why the call model? The hooks can only support a single,
> pre-defined call model. You can't have some using C and
> others using Pascal calling conventions.

Let me clarify... the call model (i.e. EXPORT_FUNC) applies to
the hook callback declaration that all procs hooked will share.
Every callback function of the hook must be typed the same way,
and the linkage model is never part of the typedef.

The linkage model defines what project the actual ap_hookproc
belongs to, how it is linked and which package (AP, CORE, API
etc) actually IMPLMENTs it.

A given hook chain is cast in stone, yes.  But why the assumption
that one hook chain shares the model of every other?  They might
not be implemented in the same library at all (many are declared
in the apache core, and perhaps others are added in an extern
module dll).  Worse - if we go __stdcall, and someone later sees
an absolute need for varargs to the functions?  Yuck.

> > I've identified all the missing tags of currently exported
> > functions, and added several, esp. in APR.  BTW... do we need
> > opendir/closedir/readdir as well as the ap_ flavors, or can
> > we deep six them?  The odder thing is that opendir, closedir
> > and readdir live in lib/apr, though we are building them into
> > ApacheCore.  Oh, was WinTimeToUnixTime to be exported?
> > These don't seem to fit the schema.
>
> Save this chunk for a second pass. Already, you've listed a
> whole bunch of things... the more you lump into a single patch,
> the HARDER it is for people to review it properly.

Agreed, although what library the *dir functions belong to define
which export macros they use... but read on...

> If at all possible, use smaller, discrete patches rather than a giant
> mother patch.

Ok, then my thought would be

1) Patches to the .dsp project and .mak macro files.  We can leave
   the SHARED_MODULE defs, and add the appropriate _DLL_EXPORT
   and _DLL_IMPORT defs to prepare the way.

2) Update a single library at a time.  Start with regex, the simplest
   example to start with.

3) Proceed to apr.  By now we ought to figure out where opendir et al
   belong.  Since it is stand alone today, this will be the place
   others can begin to play with alternate models.

4) Update ap with the ap_hooks update to the core.  By then I should
   have enough feedback on the globals, and what needs to move to
   the core can be moved.

5) Update apachecore and the modules with any lingering declarations.

6) Add an example alternate build (single executable non-exported
   model for speed benchmarking perhaps?)  Let others propose
   additional models, esp. in conjunction with alternate MPMs.

Think this may make the overall changes digestable?  I'll submit steps 1)
and 2) later today.

> > Would you care, as well, if we roll os.h and os.c into the
> > ApacheCore project [dsp] and deep six the ApacheOS [dsp]
> > project?  If not, I should define an set of OS_EXPORT* defs
> > to them, and drag back out all the os\win32 stuff back
> > into ApacheOS.  This doesn't appeal to me :}
>
> Defer to a second pass rather than worry about it now.

Addressing this in step 5 postpones this decision.  I'll treat it
as API_ and add the API_DLL_EXPORT tag to this dsp project, but
won't take any further action now.

> Second, refer to the files as .dsp files. Every time you say
> "project", I think of the development effort.

Agreed - my appologies!

Thanks for your feedback, I'm sure this will make the proposal more
manageable.