comment
This commit is contained in:
parent
8a84ddc061
commit
a5511c32d7
1 changed files with 25 additions and 0 deletions
|
@ -0,0 +1,25 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="joey"
|
||||||
|
subject="""comment 1"""
|
||||||
|
date="2021-01-04T17:50:55Z"
|
||||||
|
content="""
|
||||||
|
All of this is explained by --time-limit being implemented as a
|
||||||
|
hack that throws an exception. Problem being that, the new streaming seeker
|
||||||
|
checks matchers in a separate thread and having that thread die of an
|
||||||
|
exception probably causes the hang. Also, since it checks the matcher
|
||||||
|
before streaming through git, there's a buffer of perhaps many files
|
||||||
|
that builds up before the time limit is reached, so those can go on to be
|
||||||
|
processed, even after it's said the time limit is reached. Aaad, since it
|
||||||
|
runs cleanup actions, this might leave fsck with its database closed
|
||||||
|
but trying to use it.
|
||||||
|
|
||||||
|
--time-limit could be removed from git-annex entirely. The `timeout`
|
||||||
|
command can be used with git-annex. But fsck db flush and close doesn't
|
||||||
|
happen when git-annex gets SIGINT and do with --time-limit. So this would
|
||||||
|
need maybe a SIGINT handler that runs cleanup actions? And then git-annex
|
||||||
|
would run some perhaps expensive cleanup actions whenever ctrl-c'd, which
|
||||||
|
might not be desirable since normally that's not necessary.
|
||||||
|
|
||||||
|
Or, it needs to not be implemented in this hackish way, but as another
|
||||||
|
check that's done before starting processing a seeked file.
|
||||||
|
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue