GNOME Bugzilla – Bug 706456
pull is still racy
Last modified: 2014-02-21 20:14:51 UTC
I haven't debugged this, but it appears to happen occasionally on the loaded build server.
The original commit was:
Then some follow up fixes which helped but didn't quite fix it:
Created attachment 266688 [details]
I caught an instance of this in action with newly added debugging prints.
We can see here that the problem is that there are pending content requests in flight from the metadata scan thread to the main thread, but the main thread has received idle status and chosen to exit.
Going to mark this one closed, will reopen if it reoccurs.
Sadly, still happening =(
$ ln -s blah /ostree/repo/transaction
$ rm /ostree/repo/refs/remotes -rf
Then do a pull again.
*** Bug 724115 has been marked as a duplicate of this bug. ***
Created attachment 269936 [details] [review]
pull: Remove explicit threading
Mixing async and threads has proved to be too much for my little mind.
It has race conditions that I've tried repeatedly to fix, but failed.
The threading here was scanning metadata objects - and there are
two parts to that:
1) Physically loading them from disk
2) Parsing them
Now #1 has been partially addressed by avoiding a storm of lstat() if
we're starting from a known working state. If pull gets interrupted,
then we do need to rescan all objects. Also, we can address this with
local metadata packfiles.
deep recursion though while we also have outstanding HTTP.
Anyways, let's move the needle back to reliability, and readd speed
Looks ok to me, the one thing that did confuse me for a while is that the phase variable implicitely is set to OSTREE_PULL_PHASE_FETCHING_REFS (by assuming the first enum field will be 0).
Good point, fixed. Anything to make this code clearer for the inevitable time when I have to debug it two years on and I've forgotten how it works...
Thanks for looking at this!