Eric Kafe

https://github.com/nltk/nltk/commit/9ad1956d4f665d88b6ab26486bac779bd7352e63 fixed #3193.

Obviously, this PR is less relevant, now that #3193 is solved otherwise. There may still be a case for iterators, though that could go into a different PR.

@naktinis, does this PR solve a currently known problem? In particular, it would be great to know if it solves any of the many many open issues concerning NLTK download...

@naktinis, your 5-point sequence above appears very plausible. However, if your assumption is correct, then we should expect this sequence to also have caused some of the many issues related...

Thanks @naktinis for the issue and the test script. Your scenario seems plausible, because the NLTK downloader dates back to a time where running multiple parallel processes was less common...

@naktinis, sorry for my now deleted suggestion by Copilot about a lock mechanism. It proved useless, and further dialog with Copilot was frustrating and a complete waste of time.

The real problem is to avoid multiple useless downloads of the same file, because script kids can use this vulnerability to launch a distributed attack on the download servers. Writing...

Thanks @naktinis. Yes, I agree that once a working lock is in place to prevent useless multiple downloads, then writing files atomically could be a nice complement. But the first...

Thanks @naktinis, but I prefer not to add yet another dependency. Python already has an RLock mechanism that solves #3248, When you only download each file once, there is no...

@naktinis, now #3327 uses a multiprocessing Manager dictionary of booleans to emulate locks. Would you consider that, to prevent your race conditions?