[Bug 750397] CRITICAL: Race condition in GstBus

[GStreamer (GNOME Bugzilla)]

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

--- Comment #40 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
For the semaphore, as you mentioned because waiting and decreasing it is
combined on Windows, this won't be usable as is. We have no control over what
GMainContext does with the semaphore in relation to calling dispatch. It would
possibly wait multiple times on the same semaphore before calling dispatch.

Also gst_poll_wait() would decrease the semaphore then, and removing the item
from the bus another time... while on POSIX waiting would have no effect on the
"fill level" of the socket, only removing an item.

We would fundamentally change the external behaviour of GstPoll here between
different platforms, which is not a solution. (Which also means that we can't
make it blocking on POSIX but not on Windows)


For the blocking implementation, if I'm not mistaken we will need to read()
whenever the counter goes to <= 0 (not just == 0), and we need to write()
whenever it was <= 0 before. Otherwise we might end up with control_pending==0,
release_wakeup(), control_pending goes to -1, we don't read/block but instead
return TRUE as if reading was successful.


Also if we block, for release_all_wakeup() we would need to know the exact fill
level of the socket to read exactly that many bytes... Some counter, which
would need to be protected by a mutex because of the reasons we talked about
all the time here now.

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