Merge lp:~chipaca/snappy/lock-ness into lp:~snappy-dev/snappy/snappy-moved-to-github
| Status: | Needs review |
|---|---|
| Proposed branch: | lp:~chipaca/snappy/lock-ness |
| Merge into: | lp:~snappy-dev/snappy/snappy-moved-to-github |
| Diff against target: |
988 lines (+597/-51) 8 files modified
cmd/snappy/common.go (+4/-5) daemon/api.go (+53/-4) daemon/api_test.go (+24/-40) daemon/daemon.go (+4/-0) daemon/daemon_test.go (+23/-2) daemon/mmutex/mmutex.go (+213/-0) daemon/mmutex/mmutex_test.go (+274/-0) dirs/dirs.go (+2/-0) |
| To merge this branch: | bzr merge lp:~chipaca/snappy/lock-ness |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Gustavo Niemeyer | 2015-10-15 | Needs Information on 2015-10-21 | |
|
Review via email:
|
|||
Commit Message
REST API now uses hierarchical package-grained locking.
Description of the Change
Moo. TeX. What's not to like.
| Michael Vogt (mvo) wrote : | # |
| Michael Vogt (mvo) wrote : | # |
Fwiw, I love the branch title :P
| John Lenton (chipaca) 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 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.
I can of course move the mmutex package one level down, but I don't think that's what you meant :)
| Sergio Schvezov (sergiusens) wrote : | # |
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://
>
> I can of course move the mmutex package one level down, but I don't think
> that's what you meant :)
>
>
| Michael Vogt (mvo) wrote : | # |
Thanks for the branch and the explanation. One question inline and some minor stuff inline. I'm fine approving once the question is answered. In any case I read again tomorrow morning with a fresh mind, its not trivial (for me).
| Gustavo Niemeyer (niemeyer) wrote : | # |
Gustavo Niemeyer, [21.10.15 10:16]
@chipaca I'm lacking some context for why we'd want that locked-
John Lenton, [21.10.15 10:17]
@niemeyer you mean the mutex inside the mmutex, or you mean the whole branch?
Gustavo Niemeyer, [21.10.15 10:17]
I mean the whole thing
John Lenton, [21.10.15 10:18]
@niemeyer well, we need some kind of a lock, to avoid people doing things at the same time and putting us in an unknown state
John Lenton, [21.10.15 10:19]
@niemeyer and a single, global lock didn't seem like a good idea
Gustavo Niemeyer, [21.10.15 10:19]
@chipaca In general we try to accommodate for people doing things at the same time instead, and prevent the actual critical things that cannot be mutated at once from being mutated at once
John Lenton, [21.10.15 10:19]
@niemeyer yes, in general we do
Gustavo Niemeyer, [21.10.15 10:20]
@chipaca Right, thus why I'm trying to understand how this locking system fits
John Lenton, [21.10.15 10:24]
@niemeyer it fits in that most of snappy is still the commandline one-shot thing, which has a filesystem-based lock by necessity to prevent different invocations of it to collide
John Lenton, [21.10.15 10:25]
@niemeyer a refactor of the level needed to move it to accomplish this exclusion without explicit locks is beyond the scope of the work we can do right now
Gustavo Niemeyer, [21.10.15 10:25]
@Chipaca So keep the filesystem locks?
Gustavo Niemeyer, [21.10.15 10:26]
@chipaca Being in a hurry and doing a big complex locking system doesn't feel compatible
John Lenton, [21.10.15 10:27]
this isn't a big complex locking system, imo
John Lenton, [21.10.15 10:27]
the filesystem lock is still there
Gustavo Niemeyer, [21.10.15 10:27]
@Chipaca Rather than one big central system, it would feel much better to me to give the proper places in the code authority for their own concurrency handling
John Lenton, [21.10.15 10:28]
@niemeyer isn't that what this does?
Gustavo Niemeyer, [21.10.15 10:29]
@chipaca That often amounts to a single local mutex, if at all
Gustavo Niemeyer, [21.10.15 10:29]
@chipaca So, again, I may well not be aware of the use case, but it feels like the use case is what we should be talking about
Gustavo Niemeyer, [21.10.15 10:30]
@chipaca It feels complex to me, and it feels complex to mvo, FWIW
John Lenton, [21.10.15 10:31]
yes, but less than 200 lines of code including whitespace and comments is not "big and complex"
John Lenton, [21.10.15 10:31]
anyway, the use case
Gustavo Niemeyer, [21.10.15 10:32]
@chipaca mutex.go is 126 lines long
Gustavo Niemeyer, [21.10.15 10:32]
and a lot of it is docs :)
Gustavo Niemeyer, [21.10.15 10:33]
But I digress
John Lenton, [21.10.15 10:33]
plus 137 for rwmutex
Gustavo Niemeyer, [21.10.15 10:33]
The key here is the use case.. if we need it, so be it, but I'm not yet understanding how this would fit in that cannot be solved by something simpler
John Lenton, [21.10.15 10:34]
when somebody we need a list of packages, or services, etc, we need to avoid people installing/
John Lenton, [21.10.15 10:34]
when people operate on a package, we need to stop people operating on that package for a b...
| Michael Vogt (mvo) wrote : | # |
Thanks for your replies, I replied inline as well.
Unmerged revisions
- 772. By John Lenton on 2015-10-15
-
Introducing the MMutex. It is not a cow in affordable clothing.
- 771. By John Lenton on 2015-10-14
-
Committing in search for a name


Thanks for this branch! It looks good (but I need to read through it again as its quite complex at first). I got a bit of a meta-question. It seems like all the locking is done in the rest-api which is fine as its the only concurrent user of the API right now. But it also means that if someone builds on top of the snappy api he/she will have to rebuild the same locking. Is it a huge amount of work to put the locks inside snappy/* itself or is there another downside that I have not considered?