CROSS_PROCESS vs. LOCK_ALL

[Aaron Bannert <aa...@ebuilt.com>]

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'll post a patch for this as soon as Jeff and others are done making
their changes.)

-aaron

Re: CROSS_PROCESS vs. LOCK_ALL

[Justin Erenkrantz <je...@ebuilt.com>]

On Fri, Jun 29, 2001 at 10:52:13AM -0700, Aaron Bannert wrote:
> 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)

Under the policy of "less talk, more code" - submit a patch that
implements this.  =)  When we see the patch, we can discuss the relative
merits of it.  I personally need to see how the API is implemented
before rendering a verdict.  -- justin

Re: CROSS_PROCESS vs. LOCK_ALL

[Aaron Bannert <aa...@ebuilt.com>]

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 <aa...@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

Re: CROSS_PROCESS vs. LOCK_ALL

[Justin Erenkrantz <je...@ebuilt.com>]

On Fri, Jun 29, 2001 at 09:15:54AM -0400, Jeff Trawick wrote:
> Aaron Bannert <aa...@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

Re: CROSS_PROCESS vs. LOCK_ALL

[Jeff Trawick <tr...@attglobal.net>]

Aaron Bannert <aa...@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 :)

-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...