threads in ekiga are quite problematic :
(1) $ grep -r . -e _threads_ | wc -l
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
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 ?
Ekiga-devel-list mailing list