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