apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: [PATCH] apr_lock.h update to remove/fix CROSS_PROCESS vs LOCKALL
Date Wed, 04 Jul 2001 09:30:27 GMT
On Tue, Jul 03, 2001 at 03:07:30PM -0400, Jeff Trawick wrote:
> It is specific not just to the platform but to the mechanism.
> 
> I wrote a simple APR app to test this out...  I'll try to find time
> this evening to remove some bogosity, re-test, and post the app.  I
> don't think the bogosity affects the outcome but I need to
> double-check. 

But we can't run an APR app when we are in the middle of autoconf.  =)
Don't we need to have this information before we compile?  I'm sensing a
chicken and egg problem here.  Please correct me if I'm wrong.

Backing up a bit to the original point of this thread.  As I see it 
there were two things initially addressed in Aaron's patch:

1) Removing CROSS_PROCESS and making it equivalent to LOCK_ALL.
On threaded APR, a CROSS_PROCESS lock may or may not implictly
acquire a intraprocess lock.  I believe this is broken.  We 
shouldn't have a lock whose granularity is dependent upon the 
platform and lock mechanism.  In all cases that we examined (in 
APR and httpd), the intention of the CROSS_PROCESS locks should 
really be LOCK_ALL.  Because some platforms/mechanisms will acquire 
an INTRAPROCESS lock anyway with CROSS_PROCESS and others won't, the 
current behavior seems ill-defined and should be standardized.  

The LOCK_ALL behavior seems to be the correct one at the cost of a 
potential extra lock acquisition where we weren't expecting the 
INTRAPROCESS lock in the first place.  My assumption would be 
that this requesting this behavior (interprocess but not intraprocess) 
would be very rare.  I'd like to see a case where we would want to 
lock out threads from other processes and not from our own process.
Furthermore, you can't satisfy this request anyway with the current 
CROSS_PROCESS code as whether we obtain an intraprocess lock is
undefined.  You can't assume that it'll happen.

In certain cases where we know that the interprocess lock will do 
the job of the intraprocess lock, an optimization would be to 
forgo acquiring the extra intraprocess lock in the LOCK_ALL code.  
You may also forgo this intraprocess lock if APR isn't threaded.
However, we brought up the pathological case of someone using a 
threaded APR with a non-threaded app.  Is there something we can do
here to optimize this case?  Should we do something about this?  (This
seems to be what we have been discussing over the last day or so.)

However, I don't see this optimization (or lack thereof) as a 
showstopper or causing any bugs.  I do believe the current 
implementation of CROSS_PROCESS will cause bugs somewhere.  And,
while APR is fairly malleable, it'd be nice to get this right now 
rather than deal with cruft later.

2) Aaron and I were confused by the names used when examining the lock
code.  At first glance, CROSS_PROCESS and INTRAPROCESS aren't of the
same format.  Why isn't INTRAPROCESS - INTRA_PROCESS?  Or, 
CROSS_PROCESS - CROSSPROCESS?  Yes, this is completely semantic, but I 
think something needs to change (I'm a committer, so I guess I have some
say in what gets changed!).  I'd be happy enough to see INTERPROCESS
and INTRAPROCESS.  But, the POSIX naming style (PROCESS_SHARED and
PROCESS_PRIVATE) might lead to less confusion from quick glances at 
code fragments (was that an ER or RA?).

My $.02.  -- justin


Mime
View raw message