This commit is contained in:
Joey Hess 2020-07-13 17:52:03 -04:00
parent c893743819
commit e223ddb774
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 30 additions and 0 deletions

View file

@ -0,0 +1,20 @@
[[!comment format=mdwn
username="joey"
subject="""comment 4"""
date="2020-07-13T21:15:46Z"
content="""
If rsync is truely what's hanging, then commit 4c9ad1de4 can't have changed
anything to do with that. Seems more likely that the hang did not actually
involve rsync (but the debug output makes it seem like it is),
or that the hang is not fully deterministic.
Whatever it's hanging on in the first patch is apparently not involving
rsync, because rsync has exited. And it doesn't make sense that the first
patch would hang while the second one doesn't, they're doing identical
things except for extra background thread cleanup in the second patch.
As this stands, I don't feel confident enough that the second patch really
fixes this to close this. Also I'm a little bit doubtful it's really
correct, it seems possible it might cancel one of the threads before all
output is processed by them. The first patch actually seems better.
"""]]

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="joey"
subject="""comment 3"""
date="2020-07-13T21:20:19Z"
content="""
Ok, but the results for similar patches in
<https://git-annex.branchable.com/bugs/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/>
make me somewhat doubt I understand the problem, or that these hangs
are fully deterministic.
"""]]