37 lines
1.6 KiB
Markdown
37 lines
1.6 KiB
Markdown
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]]
|
|
|
|
---
|
|
|
|
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...
|