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

[Krishnan Parthasarathi]

You should upload the patch, it would make reviewing easier.



----- Original Message -----
> 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
> >
>