stop pipeline into a callback funtion.

[Enrique Ocaña González]

El Jueves, 17 de septiembre de 2015 09:55:24 Guillermo Rodriguez Garcia 
escribió:

> 2015-09-16 12:15 GMT+02:00 Alejandro Vázquez <vazlup at gmail.com>:
> >> I want to know if it is right to modify the status of a pipeline within a
> > callback.
> > The application works but I'm not sure if it can cause a problem in the
> > future.
>
> "Data probes run in pipeline streaming thread context, so callbacks
> should try to not block and generally not do any weird stuff, since
> this could have a negative impact on pipeline performance or, in case
> of bugs, cause deadlocks or crashes. More precisely, one should
> usually not call any GUI-related functions from within a probe
> callback, nor try to change the state of the pipeline [...]"
> 
> Now what you are using is not a data probe but I do not know if the
> same constrains apply. I couldn't find any information on what can and
> can't be done from a callback that was registered with
> g_signal_connect..
> 
> Can anyone shed some light here?

I've used several types of probes in the past and, in my experience, what you 
can do on them basically depends on the thread the callback runs on: if it's 
the main thread, you can change the pipeline and do GUI interaction. If not, 
better interact only with the nearest elements the probe is related to (eg: 
disconnect/reconnect elements on demand under some circumstances).

The easiest way to trigger some action on the main thread from a non-main one 
is to use g_idle_add()[1]. If you suspect that a lot of high priority actions 
might be runing on the main thread and you might suffer from starvation, 
better use g_timeout_add()[2] with a 0 timeout instead. No matter the method 
used, always remember to return G_SOURCE_REMOVE.

In a complex environment, you might need to ensure two things:

- The user_data passed to the callback can't be freed until the callback runs. 
  If you're passing a refcounted object as user_data, increase the ref counter 
  and decrease it before exiting the callback.
- If the pipeline is going to be destroyed for external reasons, you better 
  store the id somewhere when adding the idle/timeout function and then use 
  g_source_remove() to explicitly cancel the task.

Cheers.


[1] https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#g-idle-add
[2] https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#g-timeout-add

-- 
Enrique Ocaña González