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