apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@ebuilt.com>
Subject Re: [PATCH] allow an APR app to choose underlying lock mechanism
Date Mon, 25 Jun 2001 23:49:31 GMT
I attempted to propose a more elaborate form of this in one of my various
unclear messages. It may make more sense if we have two sets of function
calls (layers), one is the platform-independent stuff, and the other
is the platform-specific stuff. The former will most likely use the
latter, but both can be exposed for cases mentioned earlier in this thread.

(would it just be better if I posted a patch?)


On Mon, Jun 25, 2001 at 07:30:51PM -0400, Jeff Trawick wrote:
> Here's an idea:
> Leave apr_lock_create() alone (though I think some other folks wanna
> muck with it :) ).

(ooh ooh! me! *waves hands* :) )

> Add apr_lock_create_np() (or some gstein-approved name) which
> 1) has the OS-specific details specified in enum parameters like in
>   the apr_lock_create() patch I posted
> 2) is for Real Men/Women(tm) who won't cry if a call to it won't
>    compile on Win32 or if we get smarter later and tweak the parameter
>    list
> (I imagine that apr_lock_create() will call apr_lock_create_np() and
> tell it to use the default mechanism.)
> Okay, it's just a special name but it is clearly not in the set of
> interfaces which folks would expect to work the same everywhere.

View raw message