Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 5 Jun 2004 06:09:54 -0400 (EDT)
From: <rbb@rkbloom.net>
To: Joe Orton <joe@manyfish.co.uk>
cc: <dev@apr.apache.org>
Subject: Re: [PATCH] Strawman at fixing disjoint process locking
In-Reply-To: <20040604124229.GA2171@manyfish.co.uk>
Message-ID: <Pine.LNX.4.33L2.0406050607330.22919-100000@vangogh.rkbloom.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Fri, 4 Jun 2004, Joe Orton wrote:

> On Fri, Jun 04, 2004 at 02:31:48AM -0700, 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.
>
> But that model only works for fcntl and flock mutexes: the other three
> mechanisms on Unix (as currently implemented) simply cannot be used for
> synchronisation between processes which did not inherit a particular
> apr_proc_t structure.
>
> I think that we're looking for solutions to a non-problem here: the
> apr_proc_mutex interface is only useful on platforms with fork().  So
> let's surround the header with #if APR_HAS_FORK and be done with it?
>
> If you want to do portable synchronisation between two independent
> processes, you can use files and apr_file_lock(), right?

No.  We have names locks on _all_ platforms, which allow you to do
synchronisation between two independent processes just fine.  The only
problem is that our API doesn't know how to open the locks in the child
process.  This isn't hard to fix, but APR needs to understand which
locking types can be used proc_exec and which can't.  Once APR learns
that, this becomes almost trivial to actually fix.

Ryan