apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: cvs commit: apr STATUS
Date Tue, 12 Feb 2002 18:10:02 GMT
>From out in left field... this was sitting amidst my drafts.  Dunno how
relevant it still is.

From: "Aaron Bannert" <aaron@clove.org>
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.


View raw message