[gst-devel] library functions not returning

[David Schleef]

On Tue, Feb 17, 2004 at 04:32:01PM -0800, Leif Johnson wrote:
> On Tue, 2004-02-17 at 15:13, David Schleef wrote:
> > Actually, libcdparanoia is sitting in an infinite loop, getting
> > errors from the device and blindly retrying.  It's a bug in
> > libcdparanoia.  Unfortunately, it's not easy to fix -- it basically
> > requires pulling libcdparanoia's API out of the stone age.
> 
> Hmm, I got worried about that when the command line front-end did the
> same thing. :-/
> 
> > > So along Thomas' lines, is there any way
> > > we could modify the cdparanoia plugin so it might be more aware of
> > > errors like this ?
> > 
> > Yes, but imo it would be smarter to add such capability to GStreamer,
> > not individual elements.
> 
> So perhaps in the long run we could add some preemptive code to the
> scheduler(s) so that elements would be interrupted if they run too long?

Probably something like that.  However, imo, an infinite loop and/or
an element that holds the CPU for a long time is a bug.  It's a bad
bug, too, and I think that applications should simply pop up a window
that says "there's a bug in element X, please submit a bug with this
backtrace".

Note however that some elements could be slow for a variety of
non-buggy reasons, such as compressing a 4000x3000 video frame on
a 386 with 16 MB of RAM.  This makes it difficult to usefully
enforce a policy such as "elements should not take more than 5
seconds to process" or similar.

> It seems like adding such a watchdog to the cdparanoia element would be
> rather band-aid-ish.

Indeed.  And it would be easier to fix libcdparanoia.



dave...