Showing content from http://mail.python.org/pipermail/python-dev/attachments/20120331/1d087f4e/attachment.html below:
<p>Try reducing sys.setcheckinterval().</p>
<p>--Guido van Rossum (sent from Android phone)</p>
<div class="gmail_quote">On Mar 31, 2012 10:45 AM, "R. David Murray" <<a href="mailto:rdmurray@bitdance.com">rdmurray@bitdance.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sun, 01 Apr 2012 03:03:13 +1000, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
> On Sun, Apr 1, 2012 at 2:09 AM, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
> > Here's a different puzzle. Has anyone written a demo yet that provokes<br>
> > this RuntimeError, without cheating? (Cheating would be to mutate the<br>
> > dict from *inside* the __eq__ or __hash__ method.) If you're serious<br>
> > about revisiting this, I'd like to see at least one example of a<br>
> > program that is broken by the change. Otherwise I think the status quo<br>
> > in the 3.3 repo should prevail -- I don't want to be stymied by<br>
> > superstition.<br>
><br>
> I attached an attempt to *deliberately* break the new behaviour to the<br>
> tracker issue. It isn't actually breaking for me, so I'd like other<br>
> folks to look at it to see if I missed something in my implementation,<br>
> of if it's just genuinely that hard to induce the necessary bad timing<br>
> of a preemptive thread switch.<br>
<br>
Thanks, Nick. It looks reasonable to me, but I've only given it a quick<br>
look so far (I'll try to think about it more deeply later today).<br>
<br>
If it is indeed hard to provoke, then I'm fine with leaving the<br>
RuntimeError as a signal that the application needs to add some locking.<br>
My concern was that we'd have working production code that would start<br>
breaking. If it takes a *lot* of threads or a *lot* of mutation to<br>
trigger it, then it is going to be a lot less likely to happen anyway,<br>
since such programs are going to be much more careful about locking<br>
anyway.<br>
<br>
--David<br>
</blockquote></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4