Re: What ostree operations are safe to do concurrently

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]