Re: What ostree operations are safe to do concurrently

[Colin Walters <walters verbum org>]

On Thu, Dec 3, 2015, at 09:50 AM, Alexander Larsson wrote:

> But, what about write changes like a pull? Is this safe for multiple
> callers? If it is not, how should i protect things from problems. Do i
> need a repo-global lock, or can i somehow do partial locking?

I intended pull to be concurrent, but this bug breaks it right now:

https://bugzilla.gnome.org/show_bug.cgi?id=757611

I think if we fix that, that'd be pretty much all you need, right?

But more detail:

The OSTreeSysroot does have a locking mechanism, and
we could consider extending that to OSTreeRepo.

Rght now OSTree repos are just split out immutable files, there
isn't much opportunity for race conditions.  The only exceptions
I can think of are the partial download cache (above) and the summary file.

Down the line...we should clearly have something like pack
files (again), at least for metadata on bare repos.  That could
create races where if a pack file is generated and we delete
loose objects, a concurrent reader would see the loose object
as ENOENT.  We could handle this ENOENT by
re-scanning for new pack files, and trying the object lookup again.