Re: What ostree operations are safe to do concurrently

["Jasper St. Pierre" <jstpierre mecheye net>]

Wouldn't a better, lockless solution be to require that the objects
are only moved from tmp/ to the loose-objects/ directory only after
their parent is in the directory?

Although this is likely hard to track.

On Thu, Dec 3, 2015 at 6:02 PM, Colin Walters <walters verbum org> wrote:
> On Thu, Dec 3, 2015, at 12:26 PM, Alexander Larsson wrote:
> > Well, that would fix the pull, but what about remove. I mean, we do
> > want to support uninstall apps, and we call ostree_repo_prune with
> > depth=0 on updates. This can break in-progress pulls at the very least.
> > I can also imagine it breaking if you do a prune and update a ref
> > halfway that things would break.
>
> Ah, yes.  This case for "system" ostree is presently covered by the
> `OstreeSysroot` lock.
>
> > Maybe I can have some kind of reader-writer lock that we take (for
> > write) on uninstall to protect any ongoing pulls (they take a read
> > lock). We could also skip the prune if any other operation is ongoing,
> > as it will be run eventually anyway.
>
> I'd be fine having it in `OstreeRepo` too.  It's presently not reader-writer,
> doing that would need some sort of shared memory negotiation I think.
> _______________________________________________
> ostree-list mailing list
> ostree-list gnome org
> https://mail.gnome.org/mailman/listinfo/ostree-list



-- 
  Jasper