apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@ebuilt.com>
Subject Re: [PATCH] apr_lock.h update to remove/fix CROSS_PROCESS vs LOCKALL
Date Wed, 04 Jul 2001 16:20:28 GMT
On Wed, Jul 04, 2001 at 02:30:27AM -0700, Justin Erenkrantz wrote:
> > 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.

I have a feeling he didn't mean an actual APR-linked app.

Jeff, I'd love to see what you have for this when you get a chance.


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

Actually, the problem isn't that we would want to lock out threads
in other processes and not our own threads (I don't know of any mechanism,
buggy or not, that does that). The way I see it we are mixing two different
requirements into the same set of functions -- apr_lock_*()

1. eg. prefork mpm needs to synchronize access to the accept() system call
  because of some lame thundering hurd problem or whatever they called it.
  There would be no threading involved anywhere, just simple crossprocess
  (process-group-wide really) mutexes.

2. eg. mod_acme (made that one up) allocates some shared memory to store
  it's runtime state and IPC. It is running under the threaded mpm, and
  therefore needs to synchronize access to this shared memory across
  all involved processes and their threads.


Currently, 1) would use CROSS_PROCESS, and 2) would use LOCK_ALL. This is
fine as long as a threaded app never tries to use CROSS_PROCESS and. The
problem is that we don't enforce that, nor does the name "CROSS_PROCESS"
at all discourage app authors from using it in their multi-threaded
multi-process apps. In most cases I would venture to guess that APR is
specifically built to be threaded or non-threaded depending on the mpm
we're using in APR (Caveat: what happens when APR becomes a standalone
library.)


Underlying all of this it is my belief that the single access point for
all thread types is causing this confusion in the interface, as well
as possibly inefficient and complicated implementations. But that is
another rant and I'll revisit that later. :)

> 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?).

agree++ (Can I do that? ;)

-aaron


Mime
View raw message