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



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



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