<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Threading on John Stowers</title><link>https://johnstowers.co.nz/tags/threading/</link><description>Recent content in Threading on John Stowers</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 12 Mar 2007 02:58:31 +0000</lastBuildDate><atom:link href="https://johnstowers.co.nz/tags/threading/index.xml" rel="self" type="application/rss+xml"/><item><title>Threading and (py)Gtk</title><link>https://johnstowers.co.nz/2007/03/12/threading-and-pygtk/</link><pubDate>Mon, 12 Mar 2007 02:58:31 +0000</pubDate><guid>https://johnstowers.co.nz/2007/03/12/threading-and-pygtk/</guid><description>&lt;p&gt;At the request of a few people I have made a &lt;a href="http://gist.github.com/51686" rel="noopener"&gt;demo to share&lt;/a&gt;
, showing how I do threading in a pygtk application (&lt;a href="http://www.conduit-project.org" rel="noopener"&gt;Conduit&lt;/a&gt;
). I find the following approach seems to work reliably and requires little code. Other approaches can be found &lt;a href="http://aruiz.typepad.com/siliconisland/2006/04/threads_on_pygt.html" rel="noopener"&gt;here&lt;/a&gt;
 and &lt;a href="http://live.gnome.org/PyGTK/FAQ/MainLoopAndThreading" rel="noopener"&gt;here&lt;/a&gt;
.&lt;/p&gt;
&lt;p&gt;This approach takes advantage of the fact that signal emission in glib has been threadsafe since glib 2.8 (IIRC). All communication with the GUI is done via gobject signals. There is definitely a compromise in the level of GUI fiddling that you can do, particularly when compared with the &lt;em&gt;threads_enter/leave&lt;/em&gt; approach. However, I have found this signal based approach sufficent in my case, and that it encourages me to decouple the slow blocking tasks from the GUI.&lt;/p&gt;</description></item></channel></rss>