[Gstreamer-bugs] [Bug 108263] Changed - Possible race condition in gstqueue.c

[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=108263

Changed by in7y118 at public.uni-hamburg.de.

--- shadow/108263	Wed Mar 12 23:21:20 2003
+++ shadow/108263.tmp.4445	Fri Mar 14 12:22:00 2003
@@ -38,6 +38,26 @@
 the call to g_mutex_unlock(); see the attached patch.
 
 ------- Additional Comments From janzen at pixelmetrix.com  2003-03-12 23:21 -------
 Created an attachment (id=14981)
 Patch for unlikely race condition in gstqueue.c
 
+
+------- Additional Comments From in7y118 at public.uni-hamburg.de  2003-03-14 12:21 -------
+I believe the current behaviour is correct.
+
+Imagine the following scenario:
+- The queue is full.
+- A new buffer arrives. The chain function returns via 
+gst_scheduler_interrupt to let the scheduler go on.
+- A flush event arrives on the other side of the queue, the queue is 
+emptied.
+- The scheduler reschedules the queue, the chain function goes on 
+executing. The queue has been flushed, but we're still holding a 
+buffer.
+In this case the buffer should be discarded and not put into the 
+queue, which is exactly what is done.
+
+
+As a sidenote:
+We're missing a lot of gst_buffer_unref's when returning from 
+erroneous behaviour.