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

[Julien PUYDT <jpuydt free fr>]

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 ?

Snark