> we have got a lot of information while debugging #862801 so this email > is just a quick summary about how we are supposed to use Gtk in > threaded environment. As you might know - GLib itself is threadsafe > but Gtk is not. There's very conflicting information on the internet regarding the thread safety of GTK. > According to the Gtk team, the gdk_threads_enter/leave pair should not > be used at all (and they have apparently discouraged usage of it since > early releases of Gtk2). Moreover in the current Gdk docs > (http://developer.gnome.org/gdk3/stable/gdk3-Threads.html#GDK-THREADS-ENTER:CAPS) > those functions are now marked as deprecated. They're going to have to work pretty hard to change public perception, then. > The preferred way (and now the only way) is to use g_idle_add > (GLib.idle_add) with a callback method to schedule GUI changes. The > callback method will then get called by the Gtk main loop so no > locking is needed (and GLib.idle_add performs none). But that is also > the reason why everything Gtk related must be done from the mainloop > thread either directly or via idle_add. We'll just need to make sure that the added callbacks only get run once to prevent those 100% CPU usage bugs from coming back. > If we need to wait for the callback's response (Dialog?), we should > probably use Queue.Queue's .put (in the callback) and .get (at the > place where we need the response) as Queue properly blocks while > waiting for data. I have written two decorators which will make any > function decorated with it to be executed in the main loop regardless > of the thread it was called in. We will definitely need to wait for a callback response in several places, mostly related to error handling around packaging and storage. So yeah, we'll need a mechanism for that. > This all means that gdk_threaded context manager should not be used > anywhere anymore and I am currently trying to update the code to > follow this rule. You can check the decorators (gui/utils.py) and > changes (still work in progress) in my personal threading branch at: > > http://fedorapeople.org/cgit/msivak/public_git/anaconda.git/?h=threading In commit 085cd2d3002efc7b0bbf80b98d1bf383cb48875b, last chunk, that was added for a specific case. You should be able to figure out which one via "git blame". Please verify you don't cause that issue to come back by removing that line. Thanks for taking a look into this. - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
