apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@ebuilt.com>
Subject Re: CROSS_PROCESS vs. LOCK_ALL
Date Fri, 29 Jun 2001 17:52:13 GMT
On Fri, Jun 29, 2001 at 09:55:17AM -0700, Justin Erenkrantz wrote:
> On Fri, Jun 29, 2001 at 09:15:54AM -0400, Jeff Trawick wrote:
> > Aaron Bannert <aaron@ebuilt.com> writes:
> > 
> > > Hi All,
> > > 
> > > sorry to rekindle this fire, but I want to get this settled and move on.
> > > 
> > > 
> > > In my previous posts I said that I do not see why there are both
> > > APR_CROSS_PROCESS and APR_LOCK_ALL semantics in APR's lock
> > > routines. Instead I'd like to see APR_LOCK_ALL go away, and
> > > APR_CROSS_PROCESS to provide unconditional cross-process locking
> > > regardless of the underlying platform.
> > > 
> > > The problem is that an APR_CROSS_PROCESS lock will behave differently
> > > depending on the platform implementation, and this goes against the
> > > "portable" part of APR.
> > 
> > I don't have a problem with this.  Sorry for being stupid before :)
> 
> I can commit something to APR that tosses APR_LOCKALL - this makes the
> locking code a little simpler.  However, httpd-2.0 has some instances of
> APR_LOCKALL.  I can post a patch to new-httpd that switches all of those 
> to APR_CROSS_PROCESS.  Ideally, someone with commit access to both
> repositories can apply both of them at the same time.  -- justin

If it's alright with you both, I'd rather we first consider again my
suggestion of a separate api for the two. One would handle the simple
case of interprocess (aka crossprocess) locks, treated as a simple
mutex -- since this is already implemented in a cross-platform way.
The other api would be the set of "normal" lock types, the intraprocess
ones like mutex, condition, rwlock, possibly semaphore (the concept, not
the SysV kernel thing), and whatever else comes along.

What do you think? (I've been pushing this for a week or so)

-aaron


Mime
View raw message