[gstreamer-bugs] [Bug 383102] New: set_blocked can indicated that the pad is blocking while it's still processing the peers chain function

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=383102

  GStreamer | gstreamer (core) | Ver: HEAD CVS

           Summary: set_blocked can indicated that the pad is blocking while
                    it's still processing the peers chain function
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: sjoerd at luon.net
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


Hi,

  When a pad is set to blocked (while in push mode) either gst_pad_push or
gst_pad_alloc_buffer_full can cause blocked to be signaled. Both function can
be called from different thread (notibly when the src pad your blocking is from
a queue). Thus something like the following can happen: Thread 1 pushes on the
pad, Thread 2 sets the pad to block and waits, Thread 3 does a pad_alloc call
and thus signals the blocking (even though Thread 1's push didn't necessarily
return yet!)

On a side note, it'd be nice if blocking could also be signalled if there is
_no_ dataflow currently.. Especially for live sources where you never (really)
know if there will be any dataflow.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email