1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
|
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...
|
