Re: Clutter Timeline and Clutter Timeout Pool

[Emmanuele Bassi <ebassi gmail com>]

Hi;

On 16 December 2016 at 16:27, Hieu Le Trung <hieuletrung gmail com> wrote:
> Hi Emmanuele,
>
> On Dec 16, 2016, at 8:17 AM, Emmanuele Bassi <ebassi gmail com> wrote:
>
> Hi;
>
> On 16 December 2016 at 00:52, Hieu Le Trung <hieuletrung gmail com> wrote:
>
> I'm using clutter 0.8. I wonder if there's any issue if I call
> clutter_timeline_stop during the new-frame callback?
>
>
> Welcome, time traveller from the year 2008! :-)
>
> Yes, you can call clutter_timeline_stop() within a ::new-frame
> callback; the timeline will simply remove itself from the pool.
>
>
> Yes, I know it's quite old but it's the last one with fixed point
> implementation.

I find it puzzling that you need a fixed point number implementation,
but I guess you're running on *really* old GLESv1 only embedded
hardware with terrible drivers that nobody is going to touch any more.

> I encounter crash in g_slice_free around this line
>
>       clutter_timeout_unref (l->data);
>       pool->dispatched_timeouts = g_list_delete_link
> (pool->dispatched_timeouts, l);
>
>
> And it happens during a new-frame callback and we call clutter_timeline_stop
> at the end of a timeline. The timeline is looping. Maybe we change the
> timeouts/dispatch_timeouts during the clutter_timeout_pool_dispatch.

It's been 8 years since I last saw the timeout pool code, so I may be
missing something.

You should really try and get a stack trace; if the slice allocator is
crashing in there, maybe use Valgrind to check for memory corruption.

> Checking the note, I wonder if it's relating to this one or not.
>
>  * Every timeline shares the same #ClutterTimeoutPool to decrease the
>  * possibility of starving the main loop when using many timelines
>  * at the same time; this might cause problems if you are also using
>  * a library making heavy use of threads with no GLib main loop integration.
>  *
>  * In that case you might disable the common timeline pool by setting
>  * the %CLUTTER_TIMELINE=no-pool environment variable prior to launching
>  * your application.
>
>
> Currently I try to disable the pool for now.

Disabling the timeout pool would make the timeline fall back to the
GLib main loop sources — one per timeline. If you're only using a few
timelines, that shouldn't cause any particular issue; on the other
hand, if you have many timelines, you're going to starve the other
main loop sources.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]