[Bug 736071] audiobasesink: Don't hold object lock while calling into other objects like the clock

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=736071
  GStreamer | gst-plugins-good | 1.2.1

Arun Raghavan <arun> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #287358|0                           |1
        is obsolete|                            |

--- Comment #9 from Arun Raghavan <arun at accosted.net> 2014-09-30 00:58:26 UTC ---
Created an attachment (id=287410)
 View: https://bugzilla.gnome.org/attachment.cgi?id=287410
 Review: https://bugzilla.gnome.org/review?bug=736071&attachment=287410

pulsesink: Make emitting stream status messages synchronous

The stream status messages are emitted in the PA mainloop thread, which
means the mainloop lock is taken, followed by the Gst object lock (by
gst_element_post_message()). In all other locations, the order of
locking is reversed (this is unavoidable in a bunch of cases where the
object lock is taken by GstBaseSink or GstAudioBaseSink, and then we get
control to take the mainloop lock).

The only way to guarantee that the defer callback for stream status
messages doesn't deadlock is to either stop posting those messages, or
make sure that the message emission is completed before we proceed to
any point that might take the object lock before the mainloop lock
(which is what we do after this patch).

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.