Re: [Ekiga-devel-list] Unthreading ekiga : a strategy

[Julien Puydt <jpuydt free fr>]

Damien Sandras a �it :
> Le lundi 16 avril 2007 �4:19 +0200, Julien Puydt a �it :
> > Damien Sandras a �it :
> > > It is still a C dependance part of GTK+.
> > Even kde people accept a little glib :-)
> >
> > > > I use libsigc++ for signals in my latest contact code : 
> > > > http://libsigc.sourceforge.net/
> > > I think it is better :
> > > - Endpoints fire signals
> > > - the GUI thread listens to them and acts consequently
> > Firing a signal happens in the firing thread. The endpoint will still 
> > need to push something to the gui thread, which will then fire the signal.
>
> Can't we simply fire the signal in the endpoint, and have something
> listening to it outside of it, as part of the GUI classes, and then
> triggering the appropriate signal for the GTK+ elements (in case of a
> GTK+ interface) ?

No : firing a signal means executing signal listeners. So if you fire 
the signal in a thread, you'll execute the listeners in that very same 
thread.

We will push signal emission orders somewhere, and the gui thread will 
have to fetch them there, and carry the task on.

That isn't as bad as it sounds : we could have a toolkit-free 
mutex-protected queue, push things in it, and have the toolkit thread do 
its magic to access the queue. Say we push sigc::slot<void> objects in a 
queue<sigc::slot<void> > in the endpoint (with a mutex), and a GSource 
(this is gui code, so it can use whatever it wants) picks it there and 
executes them, now in the gui thread.

Snark