Calling set_state(NULL) from glib bus error callback

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Calling set_state(NULL) from glib bus error callback

Max Paklin
Hello,

The typical reaction to getting an error posted to glib bus is to quick the
loop and hence the app.
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?

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.

Thanks,
-- Max.


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Calling set_state(NULL) from glib bus error callback

Tim-Philipp Müller-2
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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

RE: Calling set_state(NULL) from glib bus error callback

Max Paklin
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=[hidden email]
[mailto:gstreamer-devel-bounces+mpaklin=[hidden email]]
On Behalf Of Tim-Philipp Müller
Sent: Wednesday, December 07, 2011 3:28 PM
To: [hidden email]
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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel