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 ______________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --------------------------------------------------------------
