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 _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
