Try reducing sys.setcheckinterval(). --Guido van Rossum (sent from Android phone) On Mar 31, 2012 10:45 AM, "R. David Murray" <rdmur...@bitdance.com> wrote:
> On Sun, 01 Apr 2012 03:03:13 +1000, Nick Coghlan <ncogh...@gmail.com> > wrote: > > On Sun, Apr 1, 2012 at 2:09 AM, Guido van Rossum <gu...@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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
