On Thu, Mar 8, 2012 at 7:43 PM, STINNER Victor wrote:
> Python < 3.3 retries the lookup an unlimited number of times which
> lead to a crash, that's the issue fixed by my change.

How does it lead to a crash?  I think it just leads to an infinite
loop (which is worse) if the data is actually malicious, but
eventually fixes itself if the data is merely unlucky or even
ill-behaved.

Guido van Rossume:
>> Can you implement the counter without adding an extra field to the dict object?

Yes.  The logic does add complexity, but there is no per-dict charge,
and the extra logic can be isolated to a function that will normally
not be paged in.

> Add a counter requires to change the prototype of the C lookup
> function:
>    PyDictEntry *(*ma_lookup)(PyDictObject *mp, PyObject *key, Py_hash_t hash);

> I don't know if it is a problem for ABI compatibility or extension
> modules. I suppose that it is safer and simpler to not change it :-)

That should still be the signature for the primary lookup; it can do
its own delegation to a private function with an extra parameter
if/when needed.

> The numbers 0, 1 and infinity are special; all others are to be
> treated with skepticism.

Yes; it isn't clear whether to cut off after 1 retry or 3 or 10...

> Is it really useful to only retry once? Retrying once means that it
> would work in most cases, but not in some corner cases. For example,
> retrying once may hide the problem if you have only 1 client (1
> thread), but you get the exception when you have more clients (more
> threads).

Without threads, there shouldn't be any problems for innocent code.
Even with threads, the number of resets is not (for innocent code)
tied to the number of alternative threads; only to the fact that they
can run mid-lookup.

-jJ