Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <6.1.0.6.2.20040604080852.02920a28@pop3.rowe-clan.net>
Date: Fri, 04 Jun 2004 08:12:34 -0500
To: Justin Erenkrantz <justin@erenkrantz.com>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: [PATCH] Strawman at fixing disjoint process locking
Cc: dev@apr.apache.org
In-Reply-To: <213031CF0406DE1AC426A411@[10.0.1.137]>
References: <213031CF0406DE1AC426A411@[10.0.1.137]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 04:31 AM 6/4/2004, Justin Erenkrantz wrote:
>I took a look at the locking problem, and I think it can be fixed rather
>trivially.  This is a minor problem in that it only affects the case where the
>child doesn't share memory addresses - such as when happens by using apr_proc_create.  Hence, adding an 'apr_*_mutex_join' could solve the problem.

Now that proposal I like.  We will still need one flag, however, and I'd
suggest APR_LOCK_DEFAULT_NAMED, to insist to APR that it choose
a lockmech, appropriate to the platform, which will take the fname and
create a joinable mutex.  If this flag isn't passed, and no specific locking
mechansim is requested, APR is free to use any anonymous and therefore
unjoinable mechanism it prefers in apr_global_mutex_create().

Bill