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

[Shyam]

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