This is from a mail I recently sent to the devel-list, where I present an idea Damien thinks interesting but not urgent ; committing to bugzilla to keep in sight :

threads in ekiga are quite problematic :
(1) $ grep -r . -e _threads_ | wc -l
449
(2) bug #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!).