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 Tue, 03 Jul 2001 14:55:50 GMT
On Tue, Jul 03, 2001 at 07:05:19AM -0400, Jeff Trawick wrote:
> Hmmm...
> A non-threaded app needs to serialize access to a resource across
> multiple processes.
> This non-threaded app builds/runs against a threaded APR.

Problem right there.  You are going to be screwed performance-wise
anyway due to all of the needless mutex locking (PROCESS_PRIVATE aka
intraprocess) in the rest of the code.

> Before this patch:
>   we only need one lock on many platforms (app specifies
> After this patch:
>   we need two locks on many platforms (cross process and intra
>   process)
> Isn't this going to bite prefork?

Wouldn't it be better to try and determine which platforms/lock types 
we don't need the APR_PROCESS_PRIVATE lock on when they attempt to 
acquire APR_PROCESS_SHARED?  Is there some way to detect that?

And, I believe we were saying that at least when you have threads, 
that the current behavior of CROSS_PROCESS is unacceptable (as it 
leaves the behavior on your process undefined which is completely 
bogus).  So, for threaded APR, this is MUCH better, IMHO.

For PROCESS_SHARED, I guess a compromise would be to do:

create sharable mutex
if (sharable-mutex-type->flags & APR_SHARED_LOCK_DOES_NOT_LOCK_PRIVATE)
    create per-process mutex

I dunno.  We know if we don't have threads that the PRIVATE mutex is not
important.  And, if our SHARED mutex also has the force of PRIVATE, then
we don't even need to create the extra PRIVATE mutex.  Or, maybe just 
always create the PRIVATE mutex if APR_HAS_THREADS is 1 (if we don't
know if SHARED implies PRIVATE - which is our problem to begin with).

This could give the non-threaded users of APR even more reason to 
specify "--without-threads" when configuring - which they should be 
doing in the first place.

(Man, I can't stand those god-awful CROSS_PROCESS names.)  -- justin

View raw message