Jim Jewett <jimjjew...@gmail.com> added the comment: On Tue, Mar 6, 2012 at 11:56 AM, Mark Shannon wrote:
> Jim Jewett: >> Can't this be triggered by non-malicious code that just happened >> to have a python comparison and get hit with a thread switch? > So, they are writing to a dict in one thread while reading from the > same dict in another thread, without any external locks and with > keys written in Python. Correct. For example, it could be a configuration manager, or a cache, or even a worklist. If they're just adding new keys, or even deleting other (==> NOT the one being looked up) keys, why should that keep them from finding the existing, unchanged keys? >> I'm not sure how often it happens, but today it would not be visible >> to the user; after the patch, users will see a sporadic failure that >> they can't easily defend against. > I suspect, they are already seeing sporadic failures. How? The chain terminates as soon as the dict doesn't resize; without malicious intent, the odds of hitting several resizes in a row are so miniscule that it probably hasn't even slowed them down. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14205> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com