On Wed, Jul 5, 2017 at 2:03 PM, Chris Angelico <ros...@gmail.com> wrote:
> On Wed, Jul 5, 2017 at 11:50 PM, eryk sun <eryk...@gmail.com> wrote:
>> Assignment of a single variable in an unoptimized namespace isn't
>> completely immune to this -- in principle. Think __setitem__,
>> __getitem__, __hash__, and __eq__. For example:
>>
>> >>> exec('cnt = 42; cnt = 43; cnt', NoisyNS())
>> __setitem__('cnt', 42)
>> __hash__('cnt')
>> __setitem__('cnt', 43)
>> __hash__('cnt')
>> __eq__('cnt', 'cnt')
>> __getitem__('cnt')
>> __eq__('cnt', 'cnt')
>>
>> It's reasonable to assume a namespace uses a built-in dict and str
>> keys (names) -- or at least types that don't do anything unusual that
>> introduces concurrency problems.
>
> This doesn't show a potential concurrency problem. Calculating a hash
> on "cnt" is independent of other threads; the actual work of
> __setitem__ isn't visible in this view. There certainly are places
> where a context switch could cause problems (eg resizing the dict),
> but they're the dict's problem, not your Python program's - because
> there's no way you could acquire a lock without working with these
> same issues.
The work in the above special methods is arbitrary bytecode that could
do anything, and there's nothing to prevent a context switch here. The
GIL provides no protection here. In principle it could be a problem,
but in practice it is not.
--
https://mail.python.org/mailman/listinfo/python-list
