idea

1 files changed, 19 insertions, 0 deletions

diff --git a/doc/bugs/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_6_5f2ed95bcad2e3d1c4260d1fb0440052._comment b/doc/bugs/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_6_5f2ed95bcad2e3d1c4260d1fb0440052._comment
new file mode 100644
index 000000000..32f2d4dec
--- /dev/null
+++ b/doc/bugs/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_6_5f2ed95bcad2e3d1c4260d1fb0440052._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2017-10-17T17:21:27Z"
+ content="""
+Another way to approach the problem would be, when the transfer of
+the same key is already in progress by another thread of the same process, 
+wait for that thread to complete before running the requested transfer
+action.
+
+The assistant has a TransferMap of all transfers the process is running.
+That would need to be moved from the DaemonStatus to Annex state.
+
+To wait on the thread that's doing the transfer, would need to store
+a MVar or something in the TransferInfo; the ThreadId can't be waited on
+by itself.
+
+This seems much less intrusive, and just as fast as my initial approach.
+"""]]