Re: Threads and Gtk

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

 



On Thu, 2012-10-11 at 11:28 -0400, Martin Sivak wrote:
> Hi,
> 
> > GLib itself is threadsafe, but Gtk is not.
> 
> This was actually always part of the documentation. Gtk was considered thread aware, but not thread safe.
> 
> > > those functions are now marked as deprecated.
> > 
> > They're going to have to work pretty hard to change public
> > perception,
> > then.
> 
> Yep, I told them. They are telling everybody that we are using the Gtk in a wrong way, but the correct way is not really documented anywhere. And all the tutorials on the web have this either wrong or partially wrong... And there are almost none for Gtk3..
> 
> > 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.
> 
> The decorator returns False, so this should be taken care of. We just have to look at all plain idle_adds and check the return codes. 
> 
> > 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.
> 
> I just tested the @gtk_thread_wait and it does exactly this. So we should be OK.
> 
> > 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.
> 
> I did, it was needed because we had with gdk_threaded() in the code. As my branch is not using Gdk locks at all, it is meaningless now. I actually used @gtk_thread_wait for the two dialogs from UserInterface and exception.py uses idle_add so it should be OK as well.
> 
> I am testing those changes (including the infamous lockup when removing last keyboard layout :), but it takes long time as you can imagine. We also have to take a look at python-meh with Vrata to make sure everything plays well together.
Running 'kill -USR1 `cat /var/run/anaconda.pid`' should be good for
testing as it raises an exception from a separate thread.

-- 
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list


[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux