Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Date: Fri, 1 Dec 2000 06:38:23 -0800 (PST)
From: rbb@covalent.net
To: dev@apr.apache.org
cc: apr-cvs@apache.org
Subject: Re: cvs commit: apr/locks/unix locks.c
In-Reply-To: <20001201140055.5665.qmail@locus.apache.org>
Message-ID: <Pine.LNX.4.21.0012010632590.32342-100000@koj.rkbloom.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


>   Modified:    .        configure.in hints.m4 CHANGES
>                include  apr.h.in apr.hw
>                locks/unix locks.c
>   Log:
>   New config variable apr_process_lock_is_global specifies that the selected
>   inter-process lock method is sufficient for APR_LOCKALL (i.e., it blocks
>   all threads and processes).  For now, hints.m4 turns on this flag for
>   OS/390.

MHO this was put in the wrong place.  This is an internal APR flag, and
should not be in apr.h at all.  Really what this is, is an optimization,
so that we don't create an intraprocess lock if the cross-process lock
will lock the threads.  Locks and how they are setup was an area of great
contention between Manoj and myself when I was designing them, because of
lockall and cross-process locks.

I am favor of this concept, but I would like the definition hidden from
the program using APR, because I think it just confuses things.  The
program should feel free to choose the correct lock type based on need, so
it they need lockall, then they should just choose lockall, and not try to
second guess APR, that cross-process would also work.  This patch opens
the way for people to try to second guess the code.

Just to be clear again, ++1 on the concept just wouldd like the def moved
from apr.h to apr_private.h (also requires backing out the Apache change).

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------