[gst-devel] library functions not returning

[Thomas Vander Stichele]

> Yes, but imo it would be smarter to add such capability to GStreamer,
> not individual elements.

I agree, but not yet sure how we should best do this.

> > 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.

As a first stab, I was thinking of something like:
- element about to call a function that we have found can possibly
deadlock, calls a function on the core (perhaps a scheduler function,
not sure) that says "the next call I'm going to make could deadlock, so
set up an alarm on my behalf".
This call would set up a SIGPROF handler and schedule a PROF signal,
with the given amount of processing time as a timeout.  It would also do
the bookkeeping to make sure that the per-thread accounting is done
correctly (starting with a global mutex for now).  After the function
call, the element calls a function that removes the alarm, and gets
whether or not it was alarm'd through an accessor.

If it was interrupted, it might make sense to either silently note this
so on a next run this element/function doesn't call the offending
function anymore, but does appropriate fallback behaviour, or flag an
error using the error API.

Does this sound sane ?

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
I never felt so out of control
You don't even know what you're doing to me
Come on and do it to me
don't you stop
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/