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


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 ?


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