httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <>
Subject Re: [PATCH] apr_lock.h update to remove/fix CROSS_PROCESS vs LOCKALL
Date Tue, 03 Jul 2001 16:13:31 GMT
Actually, I don't think an app would ever want to specify CROSS_PROCESS as
it is currently implemented, since it is not portable. How would an app
developer create a lock that will _never_ serialize in-process threads,
and _only_ synchronize across processes?

Maybe we're trying to mix too much into this part of APR? We have
threaded vs single, multiple lock scopes, multiple lock types, multiple
implementations on multiple platforms. All this under one set of
functions -- apr_lock_*(). (But this is a whole other discussion :).

You are correct that this will affect prefork, but only when built
against a threaded APR, and only on platforms where the crossplatform
lock mechanism is not global. And even then it will only mean that the
lock mechanism is implemented with two locks instead of one.

I see your point, but I see this is a tradeoff between API clarity and
crossplatform consistency, and a small amount of efficiency in isolated


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.
> 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?
> -- 
> Jeff Trawick | | PGP public key at web site:
>              Born in Roswell... married an alien...

View raw message