1/3/2023 0 Comments Git annex tortoise![]() Locking using LockPool when doing pid locking. Until exit, with LockPool used to make that thread safe. I am leaning toward a process only taking the pid lock once and holding it So, I think it's potentially buggy in the unsafe direction of lettingĢ threads "lock" the same resource, as well as in the safe direction of But,Ī/pidLock do not use LockPoolįor fine-grained locking when pid locking is enabled. Will win at the lock and the other one will wait for it. If LockPool is used, one of those 2 threads Normally all locking in git-annex uses LockPool, which Is flirting with disaster, and perhaps it should refuse to use concurrency Is that OnlyActionOn is used and prevents two threads transferring the sameīut this makes me worry that using annex.pidlock with concurrency enabled Happening! The only reason it's not a problem, in the case of transfers Which could result in any undefinedĪnd, in all the cases where it does not fail to take the transfer lock,īut instead takes over the pid lock, we're perilously close to such a thing Solutions above is implemented, then both threads will "succeed" at lockingĮven though it's a shared pidlock. To take a lock before operating on the same resource? If either of the Now, annex.pidlock is supposed to be a big top-level lock, which is used The current pid, and handle it in the lock file take over code. Or, it could special case when the pid in the pid lock file is the same as Then multiple concurrent threads could all lock the side lock. One way to solve it would be to use a LockPool instead to take the side (This could also affect other locks than transfer locks, potentially.) When it is able to take the side lock, it treats this asĪ stale pid lock file situation, and takes over the pid lock. That returns Nothing, because another thread also happens toĭue to the concurrency, the pid lock file always already exists, so ![]() ![]() What's happening is Ĭalls trySideLock and in these failure cases, Per my setting in ~/.gitconfig (which also has annex.retry = 3) #Git annex tortoise upgrade#Upgrade supported from repository versions: 0 1 2 3 4 5 6 7Īnd this is on that "fancy" NFS mounted isilon on a local HPC (a "POSIX" mount this time). Remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external ![]() What version of git-annex are you using? On what operating system? git-annexes]$ git annex version I have dumped the output of annex list into a file and now ran grep '^_' /tmp/annex-get-freesurfer-patched-annex-1-listafter.out | awk '' | xargs git -c annex.retry=10 annex -debug get -J5 2>&1 | tee /tmp/annex-get-freesurfer-patched-annex-1-getabsent.logĪnd which finished with get: 130 failed - so clearly those original failures were not real inability to fetch content. 2>&1 | tee /tmp/annex-get-freesurfer-patched-annex-1.log whenever freesurfer]$ git config annex.retry Possibly relevant older issues/todos I ran into: It is really not pragmatic to demand looping on top of such a call to ensure that eventually we do get all content. should do its really best (up to 5 times per file) to obtain content. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |