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

[Julien PUYDT <jpuydt free fr>]

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