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
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
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)
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
become active recently :)