| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
The resumed transfer still uses a slot, so will delay other, queued
transfers from starting.
|
| |
|
|
|
|
| |
A paused transfer's thread keeps running, keeping the slot in use.
This is intentional; pausing a transfer should not let other
queued transfers to run in its place.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This doesn't quite work, because canceling a transfer sends a signal
to git-annex, but not to rsync (etc).
Looked at making git-annex run in its own process group, which could then
be killed, and would kill child processes. But, rsync checks if it's
process group is the foreground process group and doesn't show progress if
not, and when git has run git-annex, if git-annex makes a new process
group, that is not the case. Also, if git has run git-annex, ctrl-c
wouldn't be propigated to it if it made a new process group.
So this seems like a blind alley, but recording it here just in case.
|
| |
|
|
|
|
|
|
|
|
| |
Should work (untested) for transfers being run by other processes.
Not yet by transfers being run by the assistant. killThread does not
kill processes forked off by a thread. To fix this, will probably
need to make `git annex getkey` and `git annex sendkey` commands that
operate on keys, and write their own transfer info. Then the assistant
can run them, and kill them, as needed.
|
| | |
|
| |
|
|
|
|
| |
This should fix OSX/BSD issues with not noticing transfer information
files with kqueue. Now that threads are used, the thread can manage the
transfer slot allocation and deallocation by itself; much cleaner.
|
| |
|
|
|
| |
There's a bug, if a transfer process notices it needs to do nothing,
it never starts the transfer, so the slot is never freed.
|
|
|
Currently nothing waits on transfer processes.
(Second drive of the day fried. Not concentrating very well.)
|
Joey Hess