[Gluster-devel] Is there a safe way to cancel a timer ?

[Xavier Hernandez]

Would it be ok if I upload a patch with my proposal for review ?

Xavi

On 11/12/2014 11:30 AM, Xavier Hernandez wrote:
> Hi Shyam,
>
> I've been discussing this stuff with Krishnan and we ended up with a
> proposal (see attached file).
>
> There many comments to explain how it works.
>
> What do you think about this proposal ?
>
> Xavi
>
> On 11/11/2014 07:42 PM, Shyam wrote:
>> On 11/10/2014 09:59 AM, Xavier Hernandez wrote:
>>> Hi Shyam,
>>>
>>> On 11/10/2014 03:36 PM, Shyam wrote:
>>>> Hi Xavi,
>>>>
>>>> I think you are referring to the problem as I see it, and have posted
>>>> here, http://review.gluster.org/#/c/6459/1/libglusterfs/src/timer.c
>>>>
>>>> If so, there is nothing clean to handle the case in the code. Something
>>>> akin to returning a non-zero from the cancel and handling it by the
>>>> consumers is a possibility.
>>>
>>> Yes, something similar to this is what I was thinking. The solution in
>>> the patch is not enough to handle this case.
>>>
>>> But there are other cases where some more control will be needed:
>>>
>>> * Suppose a fini() function releasing resources may need to cancel a
>>> pending timer. To avoid crashes, the ideal solution would be to be sure
>>> that we don't release anything the callback might need before the
>>> callback has completely been executed or correctly canceled. This means
>>> that we would need some kind of synchronization support for timers.
>>
>> Yes, this is needed. I need to give this more thought though, my memory
>> on this problem is a bit scratchy at present.
>>
>>>
>>> * Suppose that you write a callback to release some resource after a
>>> certain amount of time and this callback is handled to a subsystem that
>>> does not know exactly what the callback does. If an external condition
>>> happens, and it's needed to execute the callback before the timeout
>>> expires, you need a way to let the callback be executed, with an
>>> indication that it haven0t been executed by a normal timeout.
>>
>> I presume this is an _simpler_ extension if we solve the one above.
>>
>>>
>>> These are only 2 possible cases where having a better timer api would be
>>> helpful. In fact the first case would be interesting for ec, that
>>> currently needs something like that. It also needs a way to detect if a
>>> callback has really been canceled or not to avoid inconsistencies.
>>>
>>> Would be acceptable to improve the current timer api ?
>>
>> Yes it would :)
>>
>> I would like to have the concurrent cancel and event having been (going
>> to) fired handled first, if possible with little the no changes in the
>> API, and the second case later. Your priorities seem to suggest the same.
>>
>> Shyam
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
>