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?) -aaron 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.
