apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amit Athavale <amit_athav...@persistent.co.in>
Subject Re: documented 1.0 showstoppers
Date Fri, 04 Jun 2004 09:01:36 GMT
Quoting Ryans solution

><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>
>
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 ;)


Thanks
Amit


rbb@rkbloom.net 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.  -- 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
>>
>>
>>    
>>
>
>
>  
>


Mime
View raw message