[Bug 750397] CRITICAL: Race condition in GstBus

[GStreamer (GNOME Bugzilla)]

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

Matt Gruenke <mgruenke at tycoint.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mgruenke at tycoint.com

--- Comment #9 from Matt Gruenke <mgruenke at tycoint.com> ---
I've got a fair amount of runtime on a simple fix.  Just clear the O_NONBLOCK
flag of bus->priv->poll->control_read_fd.fd.  I'm not sure why it was ever set,
in the first place, but I believe it's not necessary.  In fact, you might get
rid of it on the write side, as well.

Without this change, I'm not certain that even holding bus->priv->queue_lock
(the fix proposed in comment #1) will always suffice, on all platforms.  I
don't know whether any guarantees are made about how fast a byte is transferred
from the write side of a socketpair() to the read side.  If it's not guaranteed
to be atomic, then perhaps a nonblocking read could still fail, even after the
writer relinquishes the mutex.

However, if read_fd.fd is kept in blocking mode, then the atomic counter
(bus->priv->poll->control_pending) will serve as a reliable arbiter of whether
to do the read.  So, even if the read does block for a bit, it's guaranteed
that there's a byte on the way.

That said, acquiring the mutex (bus->priv->queue_lock) is certainly a good idea
(and I haven't even considered whether it's necessary for Windows).  Mutexes
are cheap (unless there's contention) and bus messages tend to be infrequent. 
So, I really don't see a good argument not to do both.

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