[Python-Dev] Issue 14417: consequences of new dict runtime error (original) (raw)

Guido van Rossum guido at python.org
Wed Apr 4 00:19:29 CEST 2012

Never mind, I got it. This always raised RuntimeError. I see this should be considered support in favor of keeping the change, since sharing dicts between threads without locking is already fraught with RuntimeErrors.

At the same time, has anyone looked at my small patch (added to the issue) that restores the retry loop without recursion?

On Tue, Apr 3, 2012 at 3:17 PM, Guido van Rossum <guido at python.org> wrote:

I'm confused. Are you saying that that program always raised RuntimeError, or that it started raising RuntimeError with the new behavior (3.3 alpha 2)?

On Tue, Apr 3, 2012 at 2:47 PM, Maciej Fijalkowski <fijall at gmail.com> wrote: On Sat, Mar 31, 2012 at 7:45 PM, R. David Murray <rdmurray at bitdance.com> wrote:

On Sun, 01 Apr 2012 03:03:13 +1000, Nick Coghlan <ncoghlan at gmail.com> wrote: > On Sun, Apr 1, 2012 at 2:09 AM, Guido van Rossum <guido at python.org> > wrote: > > Here's a different puzzle. Has anyone written a demo yet that provokes > > this RuntimeError, without cheating? (Cheating would be to mutate the > > dict from inside the eq or hash method.) If you're serious > > about revisiting this, I'd like to see at least one example of a > > program that is broken by the change. Otherwise I think the status quo > > in the 3.3 repo should prevail -- I don't want to be stymied by > > superstition. > > I attached an attempt to deliberately break the new behaviour to the > tracker issue. It isn't actually breaking for me, so I'd like other > folks to look at it to see if I missed something in my implementation, > of if it's just genuinely that hard to induce the necessary bad timing > of a preemptive thread switch. Thanks, Nick.  It looks reasonable to me, but I've only given it a quick look so far (I'll try to think about it more deeply later today). If it is indeed hard to provoke, then I'm fine with leaving the RuntimeError as a signal that the application needs to add some locking. My concern was that we'd have working production code that would start breaking.  If it takes a lot of threads or a lot of mutation to trigger it, then it is going to be a lot less likely to happen anyway, since such programs are going to be much more careful about locking anyway. --David

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com

Hm I might be missing something, but if you have multiple threads accessing a dict, already this program: http://paste.pocoo.org/show/575776/ raises RuntimeError. You'll get slightly more obscure cases than changing a size raise RuntimeError during iteration under PyPy. As far as I understood, if you're mutating while iterating, you can get a runtime error. This does not even have a custom eq or hash. Are you never iterating over dicts? Cheers, fijal -- --Guido van Rossum (python.org/~guido)

-- --Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list