[gst-devel] gst_pipeline_new and GObject-y bits
in7y118 at public.uni-hamburg.de
Sat Apr 3 06:53:01 CEST 2004
The simple, elegant and best solution is of course to check for
scheduler availablibity (at least the default scheduler) in gst_init.
Solves all your problems.
On Fri, 2 Apr 2004, Thomas Vander Stichele wrote:
> 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
> 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
> - 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
> - 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
> 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/
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
More information about the gstreamer-devel