On Thu, Nov 2, 2017 at 10:27 AM, Israel Brewster <isr...@ravnalaska.net> wrote: > >> On Nov 1, 2017, at 4:53 PM, Steve D'Aprano <steve+pyt...@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. -- https://mail.python.org/mailman/listinfo/python-list
