apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: [API PROPOSAL] apr_lock.h breakout of functionality, add cond vars
Date Wed, 29 Aug 2001 17:50:12 GMT
On Wednesday 29 August 2001 09:53, Aaron Bannert wrote:

++1.  As I have said all along, the common function for all locks, was
a point of contention between Manoj and I.  I won, but I was wrong.  It's
time to fix that mistake.

> Here are a few questions I have:
> 1) Do we also need these? I realize we're using APR_LOCKALL in some places,
> but is it really faster to have N*M threads waiting on one lock, or would
> it be the same to have N threads in one lock and M threads in another lock?
> The functions I'm talking about would be:
>    apr_global_mutex_t
>    apr_global_rwlock_t

I don't believe we need these.  I think the LOCK_ALL's that we have now can
all move to proc_locks, in fact.

> 2) Would it be useful to have an apr_proc_mutex_trylock()? Is that even
> possible with fcntl, flock, etc?

If it's possible, it would probably be useful.

> 3) Will we also be needing more widely scoped condition variables?
>    apr_proc_cond_t
>    apr_global_cond_t

My gut, is that we won't need them initially, but we should leave that possibility open.

My only other comment, is that while doing development, it would be REALLY
cool if we could have access to both API's, which should end up pointing to 
the same implementation.

Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net

View raw message