On 25 Jun 2001, Jeff Trawick wrote: > [EMAIL PROTECTED] writes: > > > > > Would it make more sense to have something that would be more > > > > specific to each lock type (mutex, semaphore, read/write locks)? > > > > > > You tell me :) > > > > > > I find the whole notion of needing to tell APR which mechanism to use > > > fairly klunky, and OS-specific stuff like this really klunky. Given > > > that premise, I don't have a big problem with APR_LOCK_DEFAULT being > > > the only thing valid for various platforms and/or lock flavors. > > > > I am beginning to see this is very klunky. Is there a better way to do > > this? I can't think of one, but this just feels ugly and bad to me. :-) > > Here's an idea: > > Leave apr_lock_create() alone (though I think some other folks wanna > muck with it :) ). > > 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.
Much better. +1. Ryan _____________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] -----------------------------------------------------------------------------
