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 release.
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 functionality
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 shm.

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