[gst-devel] library functions not returning

[Thomas Vander Stichele]

On Wed, 2004-02-18 at 15:26, in7y118 at public.uni-hamburg.de wrote:
> Quoting David Schleef <ds at schleef.org>:
> 
> > > 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.
> > 
> I don't think the correct solution to work around a problem in a library is to 
> fix it anywhere else, ever.
> GStreamer (at least not the core) is not a framework for debugging or working 
> around broken libraries. 

I disagree.  Since by its very nature it is very easy to break *all* of
GStreamer because *one* of the fifty-plus libraries isn't behaving
correctly, I should think GStreamer should try to make sure the
libraries it's using are behaving correctly.

The only other way I can think of to solve the actual issues caused by
this behaviour would be "as soon as we find such an error in any of the
libraries we use, we disable that plugin from the build."

I don't think it makes much sense to discuss theoretical cleanliness of
designs in this case.  It makes more sense to say "So it seems the gdk
pixbuf loaders can trigger an endless loop when we typefind a gzipped
file.  How do we make sure typefinding doesn't block all of GStreamer ?"

Especially if this is an issue any library can throw at us, it makes
sense to me to have mechanisms to guard against it.

> So I'd be very reluctant to include code that messes 
> with signals and does stuff to stacks.
> And it is low level and we suck a lot at low level programming especially wrt 
> portability. For proof witness our cothreads.

Yep, but that's a bogus argument.  First of all, installing timeouts on
a function are border (ie transient) cases, not steady-state changes. 
The cothread code is stuff that has to keep working as it goes, while a
signal handler could say "this broke, I'm stopping".

Also, it's not too hard I think to write test code that shows how it
works, and how signals are caught from different threads, while still
being able to recover in some way from the non-returning function call.

> I wouldn't mind adding a "wrapbin" plugin or something, I just don't think it 
> should be part of the core. 

I think it should be part of the core but easy to turn off.


> PS: Are there debugging libs tat are capable of doing this already?

Don't know.

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
"You don't need a girlfriend, you need a maid !"
"Isn't that the same thing ?"
"Uh uh, baby, you're in the wrong century."
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/