aboutsummaryrefslogtreecommitdiff
path: root/libpod/lock/in_memory_locks.go
Commit message (Collapse)AuthorAge
* Do not make renumber shut down the runtimeMatthew Heon2019-02-21
| | | | | | | | | | | | | | | The original intent behind the requirement was to ensure that, if two SHM lock structs were open at the same time, we should not make such a runtime available to the user, and should clean it up instead. It turns out that we don't even need to open a second SHM lock struct - if we get an error mapping the first one due to a lock count mismatch, we can just delete it, and it cleans itself up when it errors. So there's no reason not to return a valid runtime. Signed-off-by: Matthew Heon <matthew.heon@pm.me>
* Add initial version of renumber backendMatthew Heon2019-02-21
| | | | | | | | | Renumber is a way of renumbering container locks after the number of locks available has changed. For now, renumber only works with containers. Signed-off-by: Matthew Heon <matthew.heon@pm.me>
* Update unit tests to use in-memory lock managerMatthew Heon2019-01-04
| | | | Signed-off-by: Matthew Heon <matthew.heon@gmail.com>
* Remove runtime lockDir and add in-memory lock managerMatthew Heon2019-01-04
Remove runtime's lockDir as it is no longer needed after the lock rework. Add a trivial in-memory lock manager for unit testing Signed-off-by: Matthew Heon <matthew.heon@gmail.com>