[PATCH/RFC] apr_proc_mutex_attach()

[Dirk Groeneveld <dg...@uci.edu>]

Hi!

This patch adds apr_proc_mutex_attach() functionality to process mutexes. 
It also contains modifications to test/testprocmutex, to test the new 
functionality. I tested it on linux/x86 and mac os x. It passed.

Only SYSV semaphores have a apr_proc_mutex_attach() implementation that 
doesn't just return APR_ENOTIMPL right now. All mechanisms have _detach 
and _destroy functions. I can add others later, but I was hoping for some 
comments to avoid running down a wrong path, because there are some 
issues, and this is my first real patch.

The function table for the mutexes (apr_proc_mutex_unix_lock_methods_t) 
has changed in a binary-incompatible way. I figured that would be ok 
because that structure is never passed outside the library.

apr_proc_mutex_t itself has changed as well, also in a binary incompatible 
way. To my knowledge, only pointers to it are ever given out, but if an 
old version of apr accesses a proc mutex that was created by a new version 
or vice versa, things will go bad.

Cleaning up is very different now. If you create a lock with 
apr_proc_mutex_create(), the default cleanup action will be to destroy the 
lock. This is the same behavior that existed before the patch. If you 
create it with apr_proc_mutex_attach(), the default action is to just 
detach from it. You can override the default behavior by calling 
_destroy() or _detach() by hand. Consequently, what used to be "cleanup" 
is now "destroy". _cleanup() just calls the either _destroy() or 
_detach(), depending on the way the lock was created.

The pre-patch version allows unrelated process-families to use the same 
named mutex, at least for a few implementations. For example, in the 
implementation using posix semaphores, the semaphore is "predeleted" 
already when it is created, allowing other process-families to use the 
same name without conflict. Since the whole point of _attach() is to make 
them use the same mutex if the name is the same, that is no longer 
possible. I don't know if this will break any existing code.

For a similar reason, the practice of not using the name at all will no 
longer work. Again in the posix sems implementation, the name is 
completely ignored and replaced by apr's own semaphore naming scheme, 
because on certain platforms there are limitations to the name. These 
limitations are not exported/documented by apr, so it would confusing to 
throw APR_ENAMETOOLONG on some platforms but not on others. Limiting names 
to the lowest common denominator on all platforms is, well, limiting, and 
might break existing code. wrowe suggested hashing the name at some point. 
I'm a little scared of that because while the chance of a collision might 
be small, the effects of it happening would be extremely bad.

Thank you for any feedback you might have :-)

Dirk