1 files changed, 0 insertions, 40 deletions
diff --git a/doc/todo/assistant_threaded_runtime.mdwn b/doc/todo/assistant_threaded_runtime.mdwn
deleted file mode 100644
index 03ba66acf..000000000
--- a/doc/todo/assistant_threaded_runtime.mdwn
+++ /dev/null
@@ -1,40 +0,0 @@
-The [[design/assistant]] would be better if git-annex used ghc's threaded
-runtime (`ghc -threaded`).
-
-Currently, whenever the assistant code runs some external command, all
-threads are blocked waiting for it to finish.
-
-For transfers, the assistant works around this problem by forking separate
-upload processes, and not waiting on them until it sees an indication that
-they have finished the transfer. While this works, it's messy.. threaded
-would be better.
-
-When pulling, pushing, and merging, the assistant runs external git
-commands, and this does block all other threads. The threaded runtime would
-really help here.
-
-[[done]]; the assistant now builds with the threaded runtime.
-Some work still remains to run certian long-running external git commands
-in their own threads to prevent them blocking things, but that is easy to
-do, now. --[[Joey]] 
-
----
-
-Currently, git-annex seems unstable when built with the threaded runtime.
-The test suite tends to hang when testing add. `git-annex` occasionally
-hangs, apparently in a futex lock. This is not the assistant hanging, and
-git-annex does not otherwise use threads, so this is surprising. --[[Joey]]
-
-> I've spent a lot of time debugging this, and trying to fix it, in the
-> "threaded" branch. There are still deadlocks. --[[Joey]]
-
->> Fixed, by switching from `System.Cmd.Utils` to `System.Process`
->> --[[Joey]] 
-
----
-
-It would be possible to not use the threaded runtime. Instead, we could
-have a child process pool, with associated continuations to run after a
-child process finishes. Then periodically do a nonblocking waitpid on each
-process in the pool in turn (waiting for any child could break anything not
-using the pool!). This is probably a last resort...