[Bug 750397] CRITICAL: Race condition in GstBus
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Wed Jun 29 17:02:48 UTC 2016
https://bugzilla.gnome.org/show_bug.cgi?id=750397
--- Comment #73 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
Created attachment 330603
--> https://bugzilla.gnome.org/attachment.cgi?id=330603&action=edit
poll: Fix various race conditions with read_control() and write_control()
This addresses slightly different race conditions on Linux and Windows, and
fixes gst_poll_read_control() when control_pending == 0.
On Linux, the socketpair() used for control should not be made O_NONBLOCK.
If there's any propagation delay between set->control_write_fd.fd and
set->control_read_fd.fd, even the mutex now held will not be sufficient to
prevent a race condition. There's no benefit to using O_NONBLOCK, here.
Only liabilities.
For Windows, it's necessary to fix the race condition between testing
set->control_pending and performing WAKE_EVENT()/RELEASE_EVENT(). This is
accomplished by acquiring and holding set->lock, for both of these operations.
We could optimize the Linux version by making this Windows-specific.
For consistency with the Linux implementation, Windows' RELEASE_EVENT()
has also been made to block, although it should never happen.
Also, changed release_wakeup() to return TRUE and decrement control_pending
only when > 0. Furthermore, RELEASE_EVENT() is called only when
control_pending == 1.
Finally, changed control_pending to use normal, non-atomic arithmetic
operations, since it's now protected by set->lock.
Note: even though the underlying signaling mechanisms are blocking,
release_wakeup() is effectively non-blocking, as it will only attempt to read
from control_read_fd.fd after a byte has been written to control_write_fd.fd
or WaitForSingleObject() after it's been signaled.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list