Return-Path: 
 <dev-return-11904-apmail-apr-dev-archive=apr.apache.org@apr.apache.org>
Delivered-To: apmail-apr-dev-archive@www.apache.org
Received: (qmail 43212 invoked from network); 4 Jun 2004 14:24:59 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 4 Jun 2004 14:24:59 -0000
Received: (qmail 21244 invoked by uid 500); 4 Jun 2004 14:24:23 -0000
Delivered-To: apmail-apr-dev-archive@apr.apache.org
Received: (qmail 21147 invoked by uid 500); 4 Jun 2004 14:24:21 -0000
Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:dev@apr.apache.org>
List-Help: <mailto:dev-help@apr.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@apr.apache.org>
List-Subscribe: <mailto:dev-subscribe@apr.apache.org>
Delivered-To: mailing list dev@apr.apache.org
Received: (qmail 21077 invoked by uid 99); 4 Jun 2004 14:24:19 -0000
Date: Fri, 4 Jun 2004 10:04:22 -0400 (EDT)
From: <rbb@rkbloom.net>
To: Amit Athavale <amit_athavale@persistent.co.in>
cc: <dev@apr.apache.org>
Subject: Re: documented 1.0 showstoppers
In-Reply-To: <40C03A70.4080800@persistent.co.in>
Message-ID: <Pine.LNX.4.33L2.0406041002300.22039-100000@vangogh.rkbloom.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N



On Fri, 4 Jun 2004, Amit Athavale wrote:

> Quoting Ryans solution
>
> ><Ryan>
> >
> >
> >I've been working on this, and I don't see a solution.  I have the parameter
> >added to child_init, and the structures get allocated.  But, that doesn't solve
> >the problem, because many lock types just can't be used across an apr_proc_create.
> >
> >The only solution I can think of for this is to remove APR_DEFAULT_LOCK and
> >replace it with two macros:
> >
> >APR_DEFAULT_LOCK_INHERIT
> >and
> >APR_DEFAULT_LOCK_EXEC
> >
> >feel free to tell me to change the names.  The first (APR_DEFAULT_LOCK_INHERIT)
> >is what you use if you want to use apr_fork.  This isn't portable, but it allows
> >you to create locks that can be inherited.  The second (APR_DEFAULT_LOCK_EXEC)
> >is the portable option.  This is what you use when you want to call apr_proc_create.
> >
> >Opinions?  Any volunteers to write this code?  I'll do it if nobody else steps
> >up, but I am hoping to have less time soon, and I would really like to make more
> >progress on the test suite.
> >
> ></Ryan>
> >
> I have couple of basic questions.
>
> 1> I am not entirely clear on what would be the behavior of
> APR_DEFAULT_LOCK_EXEC
>    and apr_proc_create w.r.t current problem. Do you mean to say locks
> created with
>    APR_DEFAULT_LOCK_EXEC can not be inherited at all ?

Not that they can't be inherited, but that they can be opened from a
process with a new address space.  Just about any lock type can be
inherited, but not any can be opened from a new process.

>
> 2> How do we check lock type in _child_init() when process is spawned by
> apr_proc_create ?

You don't check it.  You basically have to assume that the user knew what
they were doing.

>
>
> I can contribute to this if idea is acceptable to all and most
> importantly idea
> is entirely clear to me ;)

I'm off-line for a while, new baby born this morning, but I'll answer
questions if I have time.

Ryan