[Bug 750397] CRITICAL: Race condition in GstBus

[GStreamer (GNOME Bugzilla)]

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

--- Comment #18 from Matt Gruenke <mgruenke at tycoint.com> ---
(In reply to Sebastian Dröge (slomo) from comment #17)
> (In reply to Matt Gruenke from comment #16)
> > (In reply to Matt Gruenke from comment #13)
> > > 
> > > I've got a large amount of runtime, on the fix I mentioned in comment #9.
> > 
> > I forgot to mention that I'm not using any additional mutex or locking
> > (contrary to the last paragraph of that comment).  I've only tested this on
> > Linux.
> 
> If I understand your proposed change correctly, you can still run into the
> first situation I mentioned in the commit message.

The atomic counter is a reliable arbiter of whether to do the read.  Adding a
mutex provides no benefit, on Linux.


> And AFAIU the blocking mode of the sockets is necessary so that we can be
> sure that always either 1 or 0 bytes are in the socket. If you would do a
> non-blocking read, you could end up reading nothing, then having 1 byte
> arriving in the socket shortly after, and then be in an inconsistent state
> again where next time a second byte is written to the socket.

Yes.  This was the bug.  The socketpair in GstPoll is put in O_NONBLOCK mode,
for some reason.  I think it's wrong.  Even with a mutex, I think the bug might
still happen, unless you make the read block.

Again, I haven't examined the Windows code path.

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