Quoting Ryans solution


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:


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.

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 ?

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

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


rbb@rkbloom.net wrote:
Here is a pointer to the e-mail:



On Thu, 3 Jun 2004, Amit Athavale wrote:

The damned locking API can't work portably as things stand today.  It
wasn't designed to be portable, and it was never tested in a portable
manner.  I posted a possible solution for this, but got no feedback at all
on my idea.  I don't have the time to work on this right now, but it is a
showstopper, and I am -1 on releasing with this issue in the code.

Just to be clear: you can't veto a release.

+1 for taking whatever the heck is in HEAD, say, in 2 weeks and calling it
1.0.  This is *so* way overdue.  If people haven't fixed it by now, it won't
get fixed anytime soon.  -- justin

Dude, the API _can't_ work.  This isn't a matter of being able to slap a
fix on it.  The locking API isn't portable, and until it is changed in
some way, can't be made portable.  So, either we rip out the whole locking
API as unusable in a portable application or we fix it, but saying that we
are releasing a portable library with an API that we _know_ for a fact to
be non-portable is complete BS.

I agree with you on this.

As a user of apr, I'll not like a major release of library (in this case
1.0) without
important functionality such as locking either broken or dropped from a
Instead users are happy using 0.x releases with known problems. If we
are taking
known problems from 0.xx releases to major release, what's the point in
releasing ?

As Ryan said 1.0 release of Apache *Portable* library with important
broken / non-*portable* seems contradicting.

As far as locking API goes, for me (and I hope for large chunk of users)
its very
important functionality. In fact I use APR only for file-io, locking and

Ryan, could you dig out that possible solution for baby developers like
me who have
become active recently :)