Re: [Ekiga-devel-list] How to limit the threadness in ekiga



Damien Sandras a écrit :
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.

The idea is that the DBUS component will become a plugin, which will just wrap the endpoint-as-GObject for DBus use (see the sample plugin code I sent privately because it's too big for the list).

Snark



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]