Calling set_state(NULL) from glib bus error callback

Max Paklin mpaklin at hotmail.com
Wed Dec 7 23:49:09 PST 2011


Thanks Tim!
I appreciate the answer.

Yes, the app calls g_main_loop_run() from one of its non-GStreamer threads
and no, I wouldn't call _state_stop() from under STREAM_LOCK. Deadlock prone
or maybe even guaranteed to deadlock.

-- Max.



-----Original Message-----
From: gstreamer-devel-bounces+mpaklin=hotmail.com at lists.freedesktop.org
[mailto:gstreamer-devel-bounces+mpaklin=hotmail.com at lists.freedesktop.org]
On Behalf Of Tim-Philipp Müller
Sent: Wednesday, December 07, 2011 3:28 PM
To: gstreamer-devel at lists.freedesktop.org
Subject: Re: Calling set_state(NULL) from glib bus error callback

On Wed, 2011-12-07 at 13:05 -0800, Max Paklin wrote:

Hi,

> The typical reaction to getting an error posted to glib bus is to 
> quick the loop and hence the app.

GStreamer bus you meant, presumably.

> I my case I have multiple pipelines running, so I can't just exit the app.
> What I want to do is to stop the failing pipeline and later delete it.
> Is it safe to call gst_element_set_state(NULL) from the bus error
callback?

Yes, assuming the main loop / main context iteration is happening in a
thread other than a thread created by GStreamer. Usually this is the case,
because usually you run gtk_main() or g_main_loop_run() from your
application's main thread.

> From what I can read in the source it seems like it should OK, but I'd 
> love for people in the know to confirm that.
> I wouldn't want to cause an occasional deadlock.

Should be fine. _set_state() is only problematic when done from the context
of a GStreamer streaming thread (e.g. a signal callback emitted by an
element, a *sync* bus watch or a pad probe callback or so).

Cheers
 -Tim

_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



More information about the gstreamer-devel mailing list