I have couple of basic questions.<Ryan> 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>
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 ;)
Thanks
Amit
[EMAIL PROTECTED] wrote:
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. -- justinDude, 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
