[Bug 736295] New: multiqueue: posts buffering message holding lock

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=736295
  GStreamer | gstreamer (core) | git

           Summary: multiqueue: posts buffering message holding lock
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: All
            Status: UNCONFIRMED
          Severity: blocker
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: thiagossantos at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


multiqueue is currently posting its buffering messages while holding the
GST_MULTI_QUEUE_MUTEX_LOCK. This is not a good practice as other operations on
it might block while the message is handled.

One of these situations appeared after fixing:
https://bugzilla.gnome.org/show_bug.cgi?id=727255

There is a deadlock with playbin and multiqueue:

Thread A (playbin exposing a group)
A.1) Gets the source-group lock
A.2) Links the new pad (causing a reconfigure event to be pushed)
A.3) Multiqueue receives the reconfigure and gets the multiqueue lock
A.4) Multiqueue handles the reconfigure

Thread B (multiqueue posting a buffering message)
B.1) Multiqueue gets its lock
B.2) Multiqueue posts the buffering message
B.3) Playbin intercepts the buffering message and needs to check if it should
pass it to the application (behavior introduced by #727255)
B.4) Playbin gets the source-group lock
B.5) Playbin decides if it should post the message or not

As you can see, threads A and B both make use of the source-group and
multiqueue lock, but as they get them in different orders it might lead to a
deadlock.

The solution to #727255 seems good enough. I believe the problem is that
multiqueue shouldn't post the message while still holding the lock. This should
be no problem as long as the messages are posted in the same order as they are
created.

-- 
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.