Re: [gst-devel] gst_pipeline_new and GObject-y bits

[Benjamin O. <in...@pu...>]

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.

Benjamin


On Fri, 2 Apr 2004, Thomas Vander Stichele wrote:

> 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/
>
>
>
>
> -------------------------------------------------------
> 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
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> gstreamer-devel mailing list
> gst...@li...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>