[Bug 750397] CRITICAL: Race condition in GstBus

[GStreamer (GNOME Bugzilla)]

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

--- Comment #46 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
Note that by considering negative values we actually implement a real semaphore
here, that can be polled by gst_poll_wait() in an asynchronous way (and
considering other sockets in the same time).

If we make the socket blocking (and INFINITE wait on Windows), we have a
blocking semaphore.

If we make the socket non-blocking (or 0-wait on Windows, which we currently
don't) then we have a non-blocking semaphore and errno tells us if there was
just no data (EWOULDBLOCK) or some other error. In case of EWOULDBLOCK we could
then decide to retry, or use gst_poll_wait() (maybe together with other sockets
again) again.


The only thing that is important is that the counter and the socket/event have
a consistent state, which we can AFAICS only get by using a mutex around them
(for the Windows case, the POSIX case should also get away with just blocking
sockets).

Note also that making it blocking breaks the GstPoll API:
gst_poll_read_control() is supposed to return FALSE when no bytes were there to
be read (which it currently also does not always do because bugs, see above).
As such, we should only really consider making it blocking if there is really
really no other way around it.

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