ges: Awkward thread restrictions for ges_timeline
This is a design problem with ges_timeline
. The problem exists in 1.16 (and probably before) and the current master branch.
The file ges-timeline.c
has a CHECK_THREAD
macro. So a number of functions will fail unless they are called on the same thread that called ges_timeline_init
. This makes no sense.
In my case, I am trying to build a GESTimeline
on a child thread, because some of the internal gstreamer code is hanging (in rare scenarios) and I need to enforce a time limit for timeline construction. Now after the timeline is built, I am back on the parent thread and I cannot call a number of basic ges_timeline_*
methods (because CHECK_THREAD
rejects my current thread id).
The CHECK_THREAD
macro is a bad design and it should be removed. In its place, you could do one of the following.
- Simply comment the methods to indicate that they are not multi-thread safe.
- Attempt to enforce some type of multi-thread safety, for example by using a re-entrant mutex to guard the functions which currently contain
CHECK_THREAD
, or by passing around some type of context object (which contains the mutex).
I recommend approach 1. It is simple and it relies on the developer to apply basic common sense about when to modify objects (i.e. on which threads).