Le mercredi 30 août 2006 à 07:45 +0200, Julien PUYDT a écrit :
> threads in ekiga are quite problematic :
> (1) $ grep -r . -e _threads_ | wc -l
> (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 :
> 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
//\ Ekiga Softphone: http://www.ekiga.org/
v_/_ FOSDEM 2006 : http://www.fosdem.org/
SIP Phone : sip:dsandras@xxxxxxxxx
Ekiga-devel-list mailing list