On Fri, Apr 6, 2018 at 10:26 AM, Ruediger Pluem <rpl...@apache.org> wrote:
>
> On 04/06/2018 09:53 AM, yla...@apache.org wrote:
>>
>> + if (!APR_RING_EMPTY(&reslist->avail_list, apr_res_t, link)) {
>
> Don't we need to lock if want to do this or is this sufficiently
> atomic? Further on don't we need to make the check and the setting of
> reslist->fifo atomic, hence both done while we hold the lock?
As I said in the other thread, I'd prefer to keep the test "light"
since we document how the helper should be used.
It's indeed racy without the lock but still good enough I think: only
the first added (or last removed) resource(s) concerned for that race
be relevant, and then the winner would have to pop (resp. push) the
resource(s) before the loser is rescheduled for anything to possibly
"malfunction", where the "malfunction" would be that the resource(s)
might not expire on time, while the time diff for a race is quite tiny
in the first place...
No crash/corruption possible in any case, a non-issue IMHO, and almost
deserved if one wants to use the API outside of its scope, it's not
like we enforce everything in APR :)
Regards,
Yann.
