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@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
