Here is a pointer to the e-mail: http://marc.theaimsgroup.com/?l=apr-dev&m=107940423312808&w=2
Ryan 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 > 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 :) > > Cheers, > ~Amit > >