Thread safety issue (I think) with defaultdict

[Ian Kelly]

On Thu, Nov 2, 2017 at 10:27 AM, Israel Brewster <israel at ravnalaska.net> wrote:
>
>> On Nov 1, 2017, at 4:53 PM, Steve D'Aprano <steve+python at pearwood.info> wrote:
>>
>> On Thu, 2 Nov 2017 05:53 am, Israel Brewster wrote:
>>
>> [...]
>>> So the end result is that the thread that "updates" the dictionary, and the
>>> thread that initially *populates* the dictionary are actually running in
>>> different processes.
>>
>> If they are in different processes, that would explain why the second
>> (non)thread sees an empty dict even after the first thread has populated it:
>>
>>
>> # from your previous post
>>> Length at get AC:  54 ID: 4524152200  Time: 2017-11-01 09:41:24.474788
>>> Length At update:  1 ID: 4524152200  Time: 2017-11-01 09:41:24.784399
>>> Length At update:  2 ID: 4524152200  Time: 2017-11-01 09:41:25.228853
>>
>>
>> You cannot rely on IDs being unique across different processes. Its an
>> unfortunately coincidence(!) that they end up with the same ID.
>
> I think it's more than a coincidence, given that it is 100% reproducible. Plus, in an earlier debug test I was calling print() on the defaultdict object, which gives output like "<defaultdict object at 0x1066467f0>", where presumably the 0x1066467f0 is a memory address (correct me if I am wrong in that). In every case, that address was the same. So still a bit puzzling.

If the empty dict is created before the process is forked then I don't
think it's all that surprising.