<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Atomic</title>
	<atom:link href="http://cosmicpercolator.com/2013/03/12/atomic/feed/" rel="self" type="application/rss+xml" />
	<link>http://cosmicpercolator.com/2013/03/12/atomic/</link>
	<description>My God, it&#039;s full of stars!</description>
	<lastBuildDate>Mon, 27 May 2013 10:41:50 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Kristján Valur</title>
		<link>http://cosmicpercolator.com/2013/03/12/atomic/comment-page-1/#comment-303</link>
		<dc:creator><![CDATA[Kristján Valur]]></dc:creator>
		<pubDate>Sat, 23 Mar 2013 16:14:09 +0000</pubDate>
		<guid isPermaLink="false">http://cosmicpercolator.com/?p=3#comment-303</guid>
		<description><![CDATA[Yes, I should have mentioned that I&lt;a href=&quot;http://morepypy.blogspot.ch/2012/05/stm-update-back-to-threads.html&quot; rel=&quot;nofollow&quot;&gt; had a conversation with Armin&lt;/a&gt; about this when he originally mentioned this on the PyPy blog.  His patch was more ambitious, and involved not releasing the GIL even when explicitly doing so around blocking IO calls or other long duration calls.
The point of my proposal is to limit ourselves to merely stopping the volountary release of the GIL, but leaving explicit GIL release alone.  This does not introduce any new deadlock cases.]]></description>
		<content:encoded><![CDATA[<p>Yes, I should have mentioned that I<a href="http://morepypy.blogspot.ch/2012/05/stm-update-back-to-threads.html" rel="nofollow"> had a conversation with Armin</a> about this when he originally mentioned this on the PyPy blog.  His patch was more ambitious, and involved not releasing the GIL even when explicitly doing so around blocking IO calls or other long duration calls.<br />
The point of my proposal is to limit ourselves to merely stopping the volountary release of the GIL, but leaving explicit GIL release alone.  This does not introduce any new deadlock cases.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nick Coghlan (@ncoghlan_dev)</title>
		<link>http://cosmicpercolator.com/2013/03/12/atomic/comment-page-1/#comment-302</link>
		<dc:creator><![CDATA[Nick Coghlan (@ncoghlan_dev)]]></dc:creator>
		<pubDate>Sat, 23 Mar 2013 15:44:12 +0000</pubDate>
		<guid isPermaLink="false">http://cosmicpercolator.com/?p=3#comment-302</guid>
		<description><![CDATA[Armin Rigo suggested much the same thing as a hook for C extensions to play with when he first started working on his STM experiment, so it sounds good to me. (Armin ultimately rejected his own patch, http://bugs.python.org/issue12850, as not sufficiently interesting, but I think a cheap &quot;threading.atomic()&quot; context manager is interesting enough to be worthwhile, particularly since it allows certain data structure manipulation code to be made safe across multiple interpreter implementations)]]></description>
		<content:encoded><![CDATA[<p>Armin Rigo suggested much the same thing as a hook for C extensions to play with when he first started working on his STM experiment, so it sounds good to me. (Armin ultimately rejected his own patch, <a href="http://bugs.python.org/issue12850" rel="nofollow">http://bugs.python.org/issue12850</a>, as not sufficiently interesting, but I think a cheap &#8220;threading.atomic()&#8221; context manager is interesting enough to be worthwhile, particularly since it allows certain data structure manipulation code to be made safe across multiple interpreter implementations)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
