BF: do not use BaseDownloader instance wide InterProcessLock - resolves stalling or errors during parallel installs #6507
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
apparently that does not play nice with multi-threading parallelization,
where (I guess) we instantiate and reuse the same Downloader across multiple
threads, and thus reusing the lock.
Bu instantiating the lock right before using it, albeit may be adding even more runtime
overhead, we are avoiding the problems with InterProcessLock.
Closes #6483 and also see harlowja/fasteners#91 for more
information. Filed also #6506 which observed while troubleshooting.
I am yet to try it on actual original HCP use case, butwith this scripthttp://www.onerussian.com/tmp/ts-parallel-download.py
and this list of urls for our store http://www.onerussian.com/tmp/store-configs.txt
/bin/rm -f /tmp/out/*; head -n 1000 /tmp/store-configs.txt | python ts-parallel-download.py
now works okedit: HCP timing on smaug: