[Bug 759535] gst_clock_id_unschedule isnt thread safe

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=759535

--- Comment #5 from James Stevenson <james at stev.org> ---

I don't mind either way. I ended up making my own equivalent function to do the
same to ensure the function had finished executing after the remove was called.
This eneded up with a glib thread, mutex, condition wait to replace the timer
usage.

So give you an example of the use case which causes the api to break for us. We
have a gstreamer element which acts as a dataflow timeout in a pipeline. It
does this by taking a timestamp of when the last time the chain function was
run.

During the state transition from paused -> playing we start the timer. The
timer then checks when the last buffer was seen and sends an event on the bus
if it exceeds a certain value. Then during the state transition from playing ->
paused we stop the timer.

However when the system is under load. It is possible to do the state
transition playing -> pause -> null and free the element before the callback
has had a chance to finish running which will in turn crash when it accesses
the already free'ed memory.

Based on how the api call is made. From what I can tell its practically
impossible to stop the bug like the above happening when the api is used with a
callback like above. So it probably points to other yet unknown bugs in
gstreamer

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.