apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: [PATCH] allow an APR app to choose underlying lock mechanism
Date Mon, 25 Jun 2001 23:52:46 GMT
On 25 Jun 2001, Jeff Trawick wrote:

> rbb@covalent.net 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                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net
-----------------------------------------------------------------------------


Mime
View raw message