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

[Stephen Cook <siti orcon net nz>]

I think this is a really good idea.  The gdk_enter / leave hack is
frustrating and good also hamper interactivity.

On Wed, 2006-08-30 at 07:45 +0200, Julien PUYDT wrote:
> 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
> _______________________________________________
> Ekiga-devel-list mailing list
> Ekiga-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/ekiga-devel-list