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.
* 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.
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 ?
Xavi
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
