For an example of how to do it without having a secondary thread do any gtk commands, see my example program in:
http://www.mail-archive.com/gtk-app-devel-list@gnome.org/msg14213.html Basically the work thread, that is taking a long time doing its thing, requests the gui thread to update the GUI by sending it requests through g_idle_add(). The GUI thread will then, when idle, attend to the routine and update the gui. Syncronization is handled by mutexes, etc. In my example I wanted a reply from the GUI thread (should I abort?) therefore the worker threads blocks until released by the main thread. Regards, Dov On Thu, Nov 4, 2010 at 12:18, Michael T. <mys...@seznam.cz> wrote: > > > > So GIMP is a single threaded software? > > > > No, but... > > > > > There's never GTK+ multithreaded activity? > > > > Indeed. > > > > If I may ask, what is the main technical problem (deeper explanation) with > using GTK+ from multiple threads? > > It is probably very application specific. For instance, in my measurement > application an extra thread is started that takes care of data acquisition. > I need to update a GTK progress bar while measuring, but since data are > acquired extremely fast I do it from the measuring thread. The main thread, > where GTK is running is of course blocked until the measurement is finished. > This is obviously using GTK from multiple threads, but so far works > perfectly. (Although, sometimes I get an occasional warning during > execution) But this is probably due to the fact, that the main thread is > blocked so the only thing that can be done is the progress bar update that > is being taken care of from the measurement thread. > > myso > _______________________________________________ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
