2016-02-09 Tom Cherry :
> On Fri, Jan 15, 2016 at 3:42 PM, Greg Hackmann
> wrote:
> > On 01/15/2016 10:02 AM, Gustavo Padovan wrote:
> >>
> >> Patches 27 and 28 are attempt to fix that. I assumed that if some code is
> >> calling fence_timeline_destroy() it wants to stop everything so I
> >>
On Fri, Jan 15, 2016 at 3:42 PM, Greg Hackmann wrote:
> On 01/15/2016 10:02 AM, Gustavo Padovan wrote:
>>
>> Patches 27 and 28 are attempt to fix that. I assumed that if some code is
>> calling fence_timeline_destroy() it wants to stop everything so I
>> worked on a solution that stops any waiter
On 15/01/2016 14:55, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> All changes to timeline value come through the user via
> fence_timeline_signal() calls. When fence_timeline_destroy() is called no
> changes on timeline->value happens hence call fence_timeline_signal() with
> no increment
2016-01-15 John Harrison :
> On 15/01/2016 14:55, Gustavo Padovan wrote:
> >From: Gustavo Padovan
> >
> >All changes to timeline value come through the user via
> >fence_timeline_signal() calls. When fence_timeline_destroy() is called no
> >changes on timeline->value happens hence call
On 01/15/2016 10:02 AM, Gustavo Padovan wrote:
> Patches 27 and 28 are attempt to fix that. I assumed that if some code is
> calling fence_timeline_destroy() it wants to stop everything so I
> worked on a solution that stops any waiter and allows the timeline to be
> destroyed.
>
> No one is using
From: Gustavo Padovan
All changes to timeline value come through the user via
fence_timeline_signal() calls. When fence_timeline_destroy() is called no
changes on timeline->value happens hence call fence_timeline_signal() with
no increment is pointless.