apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: cvs commit: apr STATUS
Date Tue, 05 Feb 2002 16:30:22 GMT
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.


View raw message