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

[Xavier Hernandez]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gf_timer.c
Type: text/x-csrc
Size: 9263 bytes
Desc: not available
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20141112/1047857c/attachment-0001.bin>