From 4bf8f45efef9cfcb59945c38277c609759d8d084 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 28 May 2020 12:22:52 -0400 Subject: [PATCH] comment --- ..._306afca0827aabc092fd99e56a5b658c._comment | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 doc/bugs/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_6_306afca0827aabc092fd99e56a5b658c._comment diff --git a/doc/bugs/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_6_306afca0827aabc092fd99e56a5b658c._comment b/doc/bugs/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_6_306afca0827aabc092fd99e56a5b658c._comment new file mode 100644 index 0000000000..a0f56c4aaa --- /dev/null +++ b/doc/bugs/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_6_306afca0827aabc092fd99e56a5b658c._comment @@ -0,0 +1,28 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 6""" + date="2020-05-28T16:15:34Z" + content=""" +So the idea here is to add a PREPARE-NONCONCURRENT or whatever for the +external to use to signal that it's not able to do anything because another +one is already running concurrently. + +If the first instance that git-annex starts up responds that way, I suppose +it would just be treated the same as PREPARE-FAILURE. + +So, if an external is being used for one git-annex command, another +git-annex command that also needs to use it would just fail to start it, +and so fail entirely. + +Just for example, git annex whereis needs to start up the external program +to check WHEREIS, and would need to fail if it responded PREPARE-NONCONCURRENT. +So a long-running git-annex copy (or even the assistant) would then prevent +other git-annex commands from working. + +So, seem this is blocked on +[[todo/external_remote_querying_transition]]. + +I'm also not really sure it's worth implementing this, is it really going +to be useful compared with external remote programs doing their own locking +around whatever operations cannot be run concurrently? +"""]]