[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.
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
