Re: cvs commit: apr STATUS

[rb...@rkbloom.net]

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

Quoting rbb@apache.org:

> rbb         2004/03/15 18:23:33
> 
>   Modified:    .        STATUS
>   Log:
>   Add a note about the problems with the locking API.  This is a
> showstopper,
>   because it keep people from being able to create a portable program that
>   uses cross-process locks.
>   
>   Revision  Changes    Path
>   1.196     +11 -1     apr/STATUS
>   
>   Index: STATUS
>   ===================================================================
>   RCS file: /home/cvs/apr/STATUS,v
>   retrieving revision 1.195
>   retrieving revision 1.196
>   diff -u -r1.195 -r1.196
>   --- STATUS	21 Nov 2003 10:42:03 -0000	1.195
>   +++ STATUS	16 Mar 2004 02:23:33 -0000	1.196
>   @@ -25,6 +25,16 @@
>    
>    RELEASE 1.0 SHOWSTOPPERS:

>    
>   +    * apr_global_mutex_child_init and apr_proc_mutex_child_init aren't
>   +      portable.  There are a variety of problems with the locking API when
> it
>   +      is used with apr_create_proc instead of apr_fork.  First,
> _child_init
>   +      doesn't take a lockmech_e parameter so it causes a segfault after
> the
>   +      apr_proc_create, because the proc_mutex field hasn't been
> initialized.
>   +      When the lockmech_e parameter is added, it _still_ doesn't work,
> because
>   +      some lock mechanisms expect to inherit from the parent process. 
> For
>   +      example, sys V semaphores don't have a file to open, so the child
> process
>   +      can't reaquire the lock.
>   +
>        * Must namespace protect all include/apr_foo.h headers.  Jon Travis
>          has especially observed these including apr within Apache-1.3.
>            Message-ID: <20...@covalent.net>
>   
>   
>   
>