>From out in left field... this was sitting amidst my drafts. Dunno how relevant it still is.
From: "Aaron Bannert" <[EMAIL PROTECTED]> Sent: Tuesday, February 05, 2002 10:30 AM > 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. Same on Win32 AFAICT... designers really never envisioned a need for cross-proc only locks when most coders on win32 end up in thread deadlocks anyways :) > > 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. I will take that name, thank you :) > > 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. > > 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. Yup. And the Win32 and OS2 MPM will be much simpler with your new apr_global_mutex_t lock, than using a crossproc [file] lock. Bill
