[gst-devel] library functions not returning

[Leif Johnson]

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?
(It's kind of fun to have our own scheduler, no ?) This kind of reminds
me of JACK.

I suppose this would be bad for pipelines in general (i.e. a plugin
might be interrupted before it could provide data to a peer), but if it
could rescue apps from such frozen plugins, it seems like it might be
worth it.

Maybe the scheduler could flag an element that was interrupted, and
signal an error to the app at that time ? Am I barking up the wrong
tree ?

> > Or perhaps, on an application level, sound-juicer
> > could use some sort of watchdog thread ?
> 
> That would be the best solution right now (for catching all
> infinite loop bugs).  Next best, the cdparanoia element should
> have its own watchdog, since it has known issues with infinite
> loops.

It seems like adding such a watchdog to the cdparanoia element would be
rather band-aid-ish. And how would one do that anyway without knowledge
of the context where the plugin will be running ? I'd go for an
app-level thing for now.

leif

-- 
Leif Morgan Johnson : http://ambient.2y.net/leif/