[Python-Dev] Intricacies of calling __eq__

[Maciej Fijalkowski]

On Tue, Mar 18, 2014 at 11:19 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 18 March 2014 19:46, Maciej Fijalkowski <fijall at gmail.com> wrote:
>>> A question: how far away will this optimization apply?
>>>
>>>     if x in d:
>>>         do_this()
>>>         do_that()
>>>         do_something_else()
>>>         spam = d[x]
>>
>> it depends what those functions do. JIT will inline them and if
>> they're small, it should work (although a modification of a different
>> dict is illegal, since aliasing is not proven), but at some point
>> it'll give up (Note that it'll also give up with a call to C releasing
>> GIL since some other thread can modify it).
>
> Surely in the presence of threads the optimisation is invalid anyway
> as other threads can run in between each opcode (I don't know how
> you'd phrase that in a way that wasn't language dependent other than
> "everywhere" :-)) so
>
>     if x in d:
>         # HERE
>         spam = d[x]
>
> d can be modified at HERE. (If d is a local variable, obviously the
> chance that another thread has access to d is a lot lower, but do you
> really do that level of alias tracking?)
>
> Paul

not in the case of JIT that *knows* where the GIL can be released. We
precisely make it not possible every few bytecodes to avoid such
situations.