From: Benjamin O. <in...@pu...> - 2003-03-21 21:16:07
|
On Wed, 19 Mar 2003, Martin Janzen wrote: > You're saying that if the queue->interrupt flag is set, the mutex > unlocked, and gst_scheduler_interrupt() returns FALSE, then at some > point between the unlock in 393 and the test in 398 the queue could > have been flushed; in which case we want to return immediately based > on the new state of queue->flush, not on its state before the unlock. > Right. gst_scheduler_interrupt instructs the scheduler to finish the current iteration. So, after a call to this function gst_bin_iterate returns. So a lot can happen while that function is executed. (one example is explained in the bug. The return value of gst_scheduler_interrupt only indicates that the current function should return asap. In the case of "FALSE", the function may go on, which it does. > If that's the case, then fair enough; my patch should not be applied, > and #108263 changed to RESOLVED/NOTABUG. (Also, it means I'll have to > remove it from the enhancement I posted as #108268. Moral of the > story: Keep these separate!!) Sorry for the false alarm. > I'll ask someone to review the bug once more and then close it (if I'm right :). And please go on digging through the code and file more bugs, mail to the list or drop on IRC and ask. I don't care if you only post false alarms as long as you review the code. Many thanks for liking GStreamer and reviewing us btw. > Yes, and line 400 looks like one instance of this. But maybe I'll > let someone more familiar with schedulers, interrupts, etc. propose > that patch! :) > I just commited a patch to HEAD to fix these leaks, so it should be in 0.6.1, too. Benjamin |