Code review comment for lp://staging/~chipaca/snappy/lock-ness

On Mon, Oct 19, 2015 at 6:47 AM, John Lenton <email address hidden>
wrote:

> Remember the intention is to move away from having multiple things
> building against "the snappy api"; clients would use the rest api. There's
> a question about what that means for u-d-f, but locking shouldn't be an
> issue for it anyway.
>

 The only thing u-d-f would need to do on its own is kernel, os and gadget
snap (bootstrapping problem); the apps and frameworks should be unpacked by
firstboot.

> The only downside to moving locking down in the call stack is that it's
> not clear where to lock, exactly, unless a lot of things grow a boolean
> "lock is already held" flag.
>

/me starts to type a reply
/me thinks http://cdn.meme.am/instances/500x/65135298.jpg

>
> I can of course move the mmutex package one level down, but I don't think
> that's what you meant :)
>
>