Re: Signal emission in multi-threading environment

[Chris Vine <chris cvine freeserve co uk>]

On Thu, 2007-11-29 at 20:07 +0800, Ben Lau wrote:
> hi all,
>
>    I am implementing a GObject (a simple video player) that creates a
> GStreamer pipeline for video processing. Soon it receives a new
> GstBuffer of video frame from the pipeline, it will emit a signal. As
> GStreamer processes the pipeline with multiple threads.  The signal
> handler may not be involved inside the main thread. If my GObject
> calls g_signal_emit() within the handler, then client's callback
> function may also not be involved from the main thread.
>
>   If the callback uses any Gdk/Gtk functions, then it may cause a race
> condition. Ofcoz it could be avoided by using
> gdk_threads_enter/gdk_threads_leave pair. However, I want to hide the
> multi-threading issue from user ,so that they don't need to care
> about.
>
>  To achieve this purpose, the signal should be emitted within the main
> thread. Could anybody suggest a method to ensure that a signal is
> emitted within the main thread?
>
>  I am thinking about to create a GSource to attach to the main
> context. Soon a new frame is ready, it will dispatch the event to my
> video player in main thread. But I wonder would it have any other
> simpler method to achieve the goal?

The callback connected to the GSignal object will execute in the thread
which emits on that object, as you have found, as a GSignal object
comprises a relatively typesafe list of callbacks/closures.

If you want a thread to pass a callback to the main program thread for
execution in the main program thread, the best thing is to use
g_idle_add(), which is thread safe.  Make sure the callback returns
FALSE.

Chris