[gst-devel] gst_pipeline_new and GObject-y bits

[Thomas Vander Stichele]

Hi,

I got a bug report on nautilus-media where the property view makes
nautilus segfault when there is no registry.  I checked our code and it
seems we still do g_error on this.  This is a relic from the days where
we didn't have error handling mechanisms, didn't worry about it, or
thought it was ok for a library to segfault if the user didn't read the
README.

I'd like to fix stuff like this, and I've put some time into looking at
how it could be done, and I'd like some feedback.

Basically, the way an app triggers this is by creating a pipeline or a
thread.  In the instance_init function, a scheduler gets set on the
pipeline/thread, and if there is no default scheduler or it can't be
created, we g_error.

Changing that to a g_warning is easy, but doesn't solve everything.  The
app just gets a GstPipeline which is not initialized correctly, and he
shouldn't be using it, but there's no way to tell.

The quick fix IMO is to change gst_pipeline_new so that it checks for
proper initialization (is there a scheduler attached), and unref the
gobject and return NULL if it wasn't.

But that led me to think how this is generally handled in GObject, since
in theory I think it'd be nice if you could do g_object_new
(GST_TYPE_PIPELINE, "name", "mypipe", NULL);

I asked some questions and looked at some example code and up to know I
found out that
a) GObject isn't designed to handle failed creation; you can't unref the
GObject that is halfway constructed from custom constructors
b) g_object_new should always return a usable object; ie all api
functions should be callable on it and functions should fail gracefully
c) Different people have suggested or implemented different workarounds:
 - one way is to have a custom _new function, and check in that if the
object was initialized properly.  This works, but has the drawback that
bindings cannot use this.  This is done for example in
bacon_video_widget.
 - another possible way is to have a boolean on the object, if it got
init'ed correctly (or check the things that should have been created on
the object), and then have all the API functions check this correctly. 
This works well when you have very little API functions for this object
(see e.g. SJExtractor)
- a third way is to set an internal error (GError for example) that the
API functions check, so the consumer gets information about what went
wrong.
- a fourth proposal was to override the object's constructor function,
and possibly return NULL from there.  It looks like this could work,
from looking at gobject code, but there are a few functions still called
on the object returned by this, and I didn't check if they deal
gracefully with NULL.

So, what are the questions I'm trying to answer ?

a) Should we work towards a situation where g_object_new
(gst_..._get_type, ...) returns a valid object, or is it just not worth
it ?
b) In the gst_pipeline_new case, is it ok if I change it to return NULL
if it failed somehow for now until we figure this out ?

Feel free to comment

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
They say if you love somebody
you have got to set them free
but I would rather be locked to you
than living in this pain and misery
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/