mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

locking in checkLiveUpdate

Browse source 
This makes sure that two threads don't check balanced preferred content at the
same time, so each thread always sees a consistent picture of what is
happening.

This does add a fairly expensive file level lock to every check of
preferred content, in commands that use prepareLiveUpdate. It would
be good to only do that when live updates are actually needed, eg when
the preferred content expression uses balanced preferred content.
This commit is contained in:
Joey Hess 2024-08-27 13:07:06 -04:00
parent 4d2f95853d
commit 8555fb88ef
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 35 additions and 22 deletions
Download patch file Download diff file Expand all files Collapse all files

8
doc/todo/git-annex_proxies.mdwn
View file

@ -35,9 +35,11 @@ Planned schedule of work:
May not be a bug, needs reproducing and analysis.
* Make sure that two threads don't check balanced preferred content at the
same time, so each thread always sees a consistent picture of what is
happening. Use locking as necessary.
* Test that live repo size data is correct and really works.
* Avoid using checkLiveUpdate except when checking a preferred content
expression that does use balanced preferred content. No reason to pay
its time penalty otherwise.
* When loading the live update table, check if PIDs in it are still
running (and are still git-annex), and if not, remove stale entries