aboutsummaryrefslogtreecommitdiff
path: root/doc/bugs/parallel_get_can_fail_some_downloads_and_require_re-getting_
diff options
context:
space:
mode:
authorGravatar Joey Hess <joeyh@joeyh.name>2017-05-25 18:27:01 -0400
committerGravatar Joey Hess <joeyh@joeyh.name>2017-05-25 18:28:23 -0400
commit893f5c6b0069bfed1750a58ee6aa38d2d98b1b18 (patch)
tree7b20f41fa2bd987888f08314c755d53d477c055b /doc/bugs/parallel_get_can_fail_some_downloads_and_require_re-getting_
parent9785222714d65ded2274723c8b0a210c6152ea36 (diff)
Avoid concurrent git-config setting problem when running concurrent threads.
See my comment. This only avoids the problem for -J; two git-annex processes started at the same time could still both try to write to .git/config and one fail. That would be very unlikely though, and it doesn't really seem worth adding an additional layer of locking around .git/config. This commit was supported by the NSF-funded DataLad project.
Diffstat (limited to 'doc/bugs/parallel_get_can_fail_some_downloads_and_require_re-getting_')
-rw-r--r--doc/bugs/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_4_480df575c68bfb37b8bb4fb43737726f._comment29
1 files changed, 29 insertions, 0 deletions
diff --git a/doc/bugs/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_4_480df575c68bfb37b8bb4fb43737726f._comment b/doc/bugs/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_4_480df575c68bfb37b8bb4fb43737726f._comment
new file mode 100644
index 000000000..3827077c2
--- /dev/null
+++ b/doc/bugs/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_4_480df575c68bfb37b8bb4fb43737726f._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2017-05-25T21:52:37Z"
+ content="""
+The .git/config concurrent access happens because the remote
+list is only generated on demand, and nothing demands it when running with
+-J until all the threads are spun up and each thread has its own state
+then, so each generates the remote list.
+
+There don't look to be any other git-config settings that
+would cause problems for concurrency other than ones run while
+generating the remote list.
+
+So, generating the remote list before starting concurrent threads
+would avoid that problem, and also leads to a slightly faster startup
+since the remote git config only has to be read once, etc.
+
+The only risk in doing that would be if generating a Remote
+opens some kind of handle, which can't be used concurrently, or
+is less efficient if only opened once and then used by multiple threads.
+
+I've audited all the Remote.*.gen methods, and they all
+seem ok. For example, Remote.External.gen sets up a worker pool
+of external special remote processes, and new ones are allocated as needed.
+And Remote.P2P.chainGen sets up a connection pool.
+
+Ok, gone ahead with this fix.
+"""]]