Hi Ben, Ben Lau schrieb: > 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. > You should use the GstBus. In the signal handler create an application message and post it to the bus. The bus will marshall data and invoke signal handler in you application thread. your app need to have signal handlers on the bus to listen for the application message. Here is an example: http://buzztard.cvs.sourceforge.net/buzztard/buzztard/src/ui/edit/main-toolbar.c?view=markup look for on_channels_negotiated()
Stefan > > 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? > > Thanks for any advise. > _______________________________________________ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
