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 (was: ap_file_t typedef)
Date Mon, 03 Apr 2000 21:17:42 GMT
On Mon, 3 Apr 2000 wrote:
> > I am failing to see why we need to have an option to build Apache under
> > different calling models. IMO, we should specify a model (cdecl), set the
> > compiler command-line switch, and toss macros like APR_THREAD_FUNC.
> > 
> > Where the Win32 code needs a _stdcall callback, that is going to happen in
> > APR most likely. That callback can explicitly use _stdcall. Otherwise,
> > let's keep the code clean and toss stuff like APR_THREAD_FUNC.
> You can't toss APR_THREAD_FUNC.  Take a look at testthread.c in the test
> directory.  This is not APR code, and it requires APR_THREAD_FUNC.
> APR_THREAD_FUNC tells the programmer this is a threads main function.
> Unless I misp-read the Windows docs (completely possible) APR_THREAD_FUNC
> is required,

[note it is still API_THREAD_FUNC in CVS right now]

True.  I just grabbed the latest CVS code. APR_THREAD_FUNC is defined as
__stdcall on Windows; otherwise, it is empty.

We can do one of two things:

1) keep APR_THREAD_FUNC and require thread functions to be declared with
   it (so we can get __stdcall inserted properly)
   [i.e. keep the status quo]

2) use a thunk when we start a thread. In threadproc/win32/thread.c, we
   call our thunk (which is a __stdcall), which in turn calls the user's
   thread function (using the predefined mode: __cdecl).

   Note that the thunk would also avoid all the casting magic that occurs
   in there right now.

I would go with (2) to minimize errors by users (who forget to use the
macro). It would isolate all knowledge of custom calling conventions into
the Win32 APR library.

Similar mappings would happen for other callbacks from the Win32 operating

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]


Greg Stein,

View raw message