Le mercredi 30 août 2006 à 07:45 +0200, Julien PUYDT a écrit : > Hi, > > threads in ekiga are quite problematic : > (1) $ grep -r . -e _threads_ | wc -l > 449 > (2) http://bugzilla.gnome.org/show_bug.cgi?id=329454 > > We can't really get rid of them, so we have to find a way to live with them. > > The work to switch to a signal/callback approach gives an occasion to > (mostly) solve the issue. > > Indeed, we'll need a GObject to wrap the endpoint, which will emit said > signals, on which the gui will live. Things will look like this at the end : > > GUI > | > v > endpoint-as-GObject > | > v > endpoint-as-C++-object > > With a transition by : > > partial new GUI partial old GUI > | | > v | > endpoint-as-GObject | > | | > v | > endpoint-as-C++-object <----- > > Now what I propose is to make the endpoint-as-GObject live and emit > signals in the glib main loop (ie: in the GUI thread) : this means all > the gui won't need any gdk_threads_* (or gnomemeeting_threads_*) calls. > > There will probably be only two places where dealing with threads will > still be needed : > (1) on the endpoint-as-GObject -> endpoint-as-C++-object transition (!) > (2) in PVideoOutputDevice_GDK, since the media streams are a place where > threads can't be avoided for performance reasons. > > How does one deal with threads in (1) ? Probably just like gstreamer > does in GstBus. > > The GstBus is an object, which contains a GQueue of messages, protected > by a GMutex. When something "interesting" happens in a thread, a message > is added to the queue (which is protected, so it's ok). The bus is > registered as a GSource to the glib main loop, so the main loop triggers > the processing of the messages from time to time (and this happens in > the GUI thread!). > > Doesn't it sound promising ?
I'm not against it, but we have to put some priorities, and as a maintainer, I would prefer that we respect them. Currently, the top priorities for next release are : 1) Implement presence support using SIP in Ekiga 2) Improve the User Interface 3) Port to GTK+ 2.10 and close all features requests in bugzilla 4) Have a functional WIN32 port 5) Incorporate your code for the address book 6) Incorporate IAX2 support When we are ready with that, we can release 3.00 around February 2007. After that, I suggest that we improve the gdk_threads_* issue using signals and callbacks. It is not that hard to do, your DBUS component already emits very interesting signals in the endpoint. Our main GUI can just reuse them. -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] _______________________________________________ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list