apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@ebuilt.com>
Subject Re: [PATCH] allow an APR app to choose underlying lock mechanism
Date Mon, 25 Jun 2001 21:21:05 GMT
I think this looks great.

Do I have any support yet for a fully-separated locks API, something
to the effect of:

Inter/cross process locks handled by:
apr_lock_interprocess_*()

Intraprocess locks handled by (these could even be POSIX):
apr_lock_mutex_*() 
apr_lock_cond_*()
apr_lock_rwlock_*()
...

(replace "*" above with each of {create, acquire, release, destroy, etc...})

I am expecting this kind of an API to work well with your changes below
(choosing the underlying lock mechanism).

Comments?

-aaron



On Mon, Jun 25, 2001 at 04:30:45PM -0400, Jeff Trawick wrote:
> (on Unix, at least)
> 
> Brain-dead changes are needed for win32, beos, and os2 to ensure that
> the new parameter to apr_lock_create() is reasonable.  I'll do it; I
> just haven't done it yet.
> 
> Only the mechanism for interprocess lock can be chosen at the moment.
> We can add that later if/when it is necessary or we can build in the
> interface now.  I don't care, but please suggest an interface if you
> want it to be in place immediately.
> 
> I've changed Apache and standard modules too and manually tweaked prefork
> and threaded to tell APR to use various lock mechanisms, but I haven't
> done any work to add any sort of configuration option to the MPMs.
> The Apache patch isn't posted anywhere because it is just more of the
> same stuff seen below.
> 
> Did anybody want this done differently?


Mime
View raw message