On Wed, Feb 06, 2002 at 12:07:58AM +1000, Brian Havard wrote: > On OS/2 the only native mechanism that has cross-process lock behaviour is > file locking (which is yuck because then you have to have a lock file). In > fact I suspect the only reason we have cross-process locks at all is that > some platforms only have file locks so the API was created to fit these > platforms' capabilities. > > Wouldn't it be more useful & portable for the cross-process lock type to > have the "lock all" behaviour, considering that on non-threaded platforms > it amounts to the same thing? I'd expect that any platform that has threads > would also have process sharable mutexes, making a "lock all" API universal > to all platforms, threaded or not.
I still may add an apr_global_mutex_t type (OtherBill doesn't agree with the name) that works the same as LOCKALL used to work. > Is it ever useful to have the cross-process behaviour in a threaded > application? (not meant as a rhetorical question but I can't think of any > cases off the top of my head). Not in a purly threaded application, but apache tends to be a hybrid. It is necessary for supporting single-threaded multi-process MPMs. Think of prefork: since most cross-process lock types on unix do not simultaneously support thread locking. fcntl() behaves like this, for example. A LOCKALL mechanism that used fcntl() would also have to use pthread locks to keep the threads synchronized, which unnecessarily burdens the lock/unlock implementations. Since prefork only needs cross-process locking, the current apr_proc_mutex mechanism is ideal. OTOH, something like perchild could benefit from an apr_global_lock_t, since it has both threads and processes that need to share a listen_rec and serialize over the accept(). The implementation could decide if it needed nested proc_mutex and thread_mutex types, or if there was a type that could do it all at once. -aaron
