Concurrent ref iterator access #2395
Conversation
If we remove a reference while we're iterating through the packed refs, the position in the iterator will be off.
This lets us work without worrying about what's happening but work on a snapshot.
|
I'd love to see this. |
|
The remote rename operation seems to suffer from the same bug, which is surfaced by libgit2/libgit2sharp#741 |
|
This seems like an acceptable short-term solution to this, but making a full copy of the sorted cache is pretty wasteful for the iterator's snapshot. The cache builds a hash table to index the entries, where the iterator just needs a simple array for sequential access. |
|
Yeah, I agree it's wasteful, but at least it's correct. @Therzok has confirmed that this fixes the issue I mentioned, so I'd be inclined to merge this and then figuring out a less memory-intensive way of snapshotting. |
|
Yes, I don't disagree. Sorry, I realize that "acceptable short-term solution" while positive in my mind, could mean "too many compromises to merge right now" which wasn't my intent. |
Concurrent ref iterator access
We may loose some packed refs by re-using the sortedcache, which may be reloaded at any time. With this, we isolate the iterator from outside changes (though only up to the point that the packed-refs can be snapshotted).
I think we should at least try to provide this kind of snapshotting in the iterator, and this also fixes what the test actually does, which is remove a ref from packing, where out offset gets out of sync with the actual contents.
Thoughts?
/cc @arrbee