| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
If there's a locking issue in this test, then it's likely not going to
resolve after a few seconds of serializing access. Lower the default 30
second lock timeout to 5 seconds to prevent the test from hanging
unnecessarily.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code has been sitting around for a while but since I disabled
it by default, I doubt anyone is really using it or relying on it.
This patch and turns on locking by default, and also drops the
API which was only public in the experimental API builds.
Conceptually these are two distinct things, and we
may actually want to split up the patches.
I don't think this will break anyone, but it's hard to say for sure.
It's also going to be hard to find out until we actually release
I suspect...
But anyone who is broken should be able to add `locking=false` into
their repo config. On the flip side Endless has been shipping with
this enabled and it is reported to help.
The reason to drop the APIs: I'm a bit concerned about the interactions over time
between libostree's use of the API and any apps that start using it.
For example, if an app specifies a SHARED lock in their code, then
later internally we decide to temporarily grab an `EXCLUSIVE`, but the
app had a second thread/process that was `EXCLUSIVE` already, and
that process was waiting on the first bit of code, then we could
deadlock. I can't think of a real world situation where this would happen
yet though.
We are likely to in the future have say `fsck` take an external lock,
`checkout` grab a shared one, etc.
Closes: #1555
Approved by: jlebon
|
|
|
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #1463
Approved by: cgwalters
|
|
|
|
|
|
|
|
|
|
|
| |
Python 3 is pickier about this. Python 2.7 has Python 3-compatible
semantics for division when the division feature is imported from the
future.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #1457
Approved by: cgwalters
|
|
|
|
|
|
|
|
|
|
| |
range in Python 3 does what xrange did in Python 2. This still works in
Python 2, it just uses a bit more memory.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #1457
Approved by: cgwalters
|
|
|
|
|
|
|
|
|
| |
This also works in Python 2.7, and is a little clearer.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #1457
Approved by: cgwalters
|
|
|
|
|
|
|
|
|
| |
I want some time to play with this more with different callers and work through
test scenarios. Let's disable the locking by default for now, but make it easy
to enable.
Closes: #1375
Approved by: jlebon
|
|
Test that concurrent commits and prunes can succeed. Mostly this is a
check that the new locking works correctly and the concurrent processes
will properly wait until they've acquired the appropriate repository
lock.
Closes: #1343
Approved by: cgwalters
|