todos

1 files changed, 29 insertions, 0 deletions

diff --git a/doc/todo/assistant_threaded_runtime.mdwn b/doc/todo/assistant_threaded_runtime.mdwn
new file mode 100644
index 000000000..095ffa435
--- /dev/null
+++ b/doc/todo/assistant_threaded_runtime.mdwn
@@ -0,0 +1,29 @@
+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.
+
+---
+
+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]]
+
+---
+
+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...