apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: [PATCH] allow an APR app to choose underlying lock mechanism
Date Mon, 25 Jun 2001 23:30:51 GMT
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

(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 | trawick@attglobal.net | PGP public key at web site:
             Born in Roswell... married an alien...

View raw message