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
> APR_CROSS_PROCESS)
>
> 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 APR_HAS_THREADS
if (sharable-mutex-type->flags & APR_SHARED_LOCK_DOES_NOT_LOCK_PRIVATE)
create per-process mutex
#endif
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
