[gst-devel] Re: [gst-cvs] soto gstreamer: gstreamer/ gstreamer/gst/

[Benjamin Otte]

On Tue, 23 Nov 2004, Martin Soto wrote:

> If the other end isn't pulling, the queue blocks. Is the same thing that
> happens when the queue is full and you try to write. Anyway, if people
> consider that a timeout would be necessary, I can work on it. The
> question is rather how this timeout would be defined, because the normal
> queue timeout would be too short, so we'd need an additional option for
> it. Or maybe we make the whole behavior optional, but I still think the
> original behavior is not that useful, so why making the queue (even)
> more complex to support it?
>
I don't care that much atm, because I'm a) focussing on 0.9, b) working
on exams right now and c) being majorly demotivated again.

But it sounds like a good idea to use a timeout and fail. Maybe use the
timeout to check if the queue is still working (that means emptying) and
only fail if it's not?
Have you thought about the case when both sides try to renegotiate the
format? Or upstream renegotiations at all?
And you probably have run our testsuites as well as totem and rb, right?
release_locks in state changes works correctly?

We'll get bug reports when the deadlocks happen...

Benjamin