[Gstreamer-bugs] [Bug 109313] New - gstqueue: writer thread not unblocked if full queue is flushed

[bugzilla-daemon at widget.gnome.org]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=109313

Changed by janzen at pixelmetrix.com.

--- shadow/109313	Wed Mar 26 22:44:55 2003
+++ shadow/109313.tmp.11687	Wed Mar 26 22:44:55 2003
@@ -0,0 +1,52 @@
+Bug#: 109313
+Product: GStreamer
+Version: 0.6.0
+OS: All
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: minor
+Priority: Normal
+Component: gstreamer (core)
+AssignedTo: gstreamer-maint at bugzilla.gnome.org                            
+ReportedBy: janzen at pixelmetrix.com               
+QAContact: gstreamer-maint at bugzilla.gnome.org
+TargetMilestone: 0.6.x
+URL: 
+Summary: gstqueue: writer thread not unblocked if full queue is flushed
+
+I have an element which, under some circumstances, needs to flush either
+the upstream (transport buffer) or downstream (frame buffer) queue (or
+maybe both; still under construction!).
+
+Flushing the downstream queue is easy:
+
+  gst_pad_push (myelement->srcpad,
+    GST_BUFFER (gst_event_new_flush ()));
+
+And if I understand correctly, flushing the upstream one is not much more
+difficult; something like this:
+
+  GstPad *peer = gst_pad_get_peer (myelement->sink_pad);
+  GstElement *src = gst_pad_get_parent (src);
+  if (GST_IS_QUEUE (src)) {
+    gst_element_set_state (src, GST_STATE_PAUSED);
+    gst_pad_send_event (peer, gst_event_new_flush ());
+    gst_element_set_state (src, GST_STATE_PLAYING);
+  }
+
+(Arguably this code shouldn't be in my element itself; instead, the element
+could generate a signal which causes the main program to flush the queue,
+for instance.  But for testing...)
+
+Anyway, the problem I found is that, if the upstream queue is full and a
+writer thread is blocked waiting for the queue to empty, that thread will
+stay blocked forever.
+
+It looks to me as though the gst_queue_handle_src_event() event function
+which flushes the queue should also wake up the writer thread.
+
+It's a trivial fix (see attached patch), and I've tested it successfully;
+but I just want to make sure that sending events upstream as I've done
+above is acceptable practice, and that the GStreamer framework in fact
+intends to support this sort of thing.  Comments...?