Ryan Bloom wrote:
Q0: Is there a better place to ask this kind of question
This is the right place.
Heh-heh. That means you get follow-ups.
Q1: I assume global locks dispatch to Process or Thread locks as appropriate, with equivalent semantics?
Pretty much. The biggest difference is that on many platforms, the process locks are global in and of themselves. In that case, we just use a process lock.
I'm not 100% clear on the sense of "global" here.
Q2: How do the global routines decide which to call?
There is no real decision to make. The global locks always use a process lock, if you configured APR with threads and the platform does not automatically lock threads when using a process lock, then a thread lock is also used.
Which suggests that if you're running threaded, you *really* win by using the apr_thread_mutex_* stuff? Seems it be nice if there was a way for the global routines to detect which of process/thread is appropriate from the httpd config or some other environmental condition? Or even on explicit init()-time signal from the caller? Seems klunky to have all these triples of routines (thread/proc/global) with identical semantics.
Q3: There is a stern warning in the global locking routines "There is considerable overhead in using this API
The warning is too stern. If you want to work in a process/thread environment...
Which I always do if I want to run in httpd in the general case, right?
Q4: I really need more or less exactly the RWLock semantics. Is there
any particular reason this is thread-only?
The reason it doesn't currently exist, is that nobody has gotten around
to implementing it. :-)
Good enough - if we do the module I'll do it; I agree it doesn't feel like rocket science, particularly given the number of pieces that are already there. -Tim
