[Bug 750397] CRITICAL: Race condition in GstBus

[GStreamer (GNOME Bugzilla)]

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

--- Comment #42 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
After some further discussions on IRC, the solution here for the time being is
likely going to be to move away from GstPoll for GstBus (to simplify the code
and not have it work around GstPoll weirdness) / GstBufferPool (to actually fix
the code), and instead of mutexes and condition variables instead. The
advantage of using lockless data structures here is basically non-existant and
it seems better to have it actually working reliable and correct before
optimizing. At a later point, someone could consider optimizing this again if
the needs arises.

For GstPoll itself it probably makes sense to go with my patches for the time
being as they seem safe without changing the behaviour of the API.


The usage of GstPoll in GstSystemClock seems safe though, so we can keep that
one. It is also having an advantage over mutexes and condition variables there
because of nanosecond vs. microsecond precision (which pthread condition
variables also have, but GLib truncates to microseconds... we could use pthread
directly here though, optionally)

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