Resolve issue where a spawn process' slab fails #1914
Conversation
Previously, if a main process' slab mapsize increases, any existing spawn processes (which have the same slabs open readonly) would get a lmdb.MapResizedError when calling slab.initdb. Now, initdb correctly handles that case.
Codecov Report
@@ Coverage Diff @@
## master #1914 +/- ##
==========================================
- Coverage 96.70% 96.61% -0.09%
==========================================
Files 139 139
Lines 26467 26470 +3
==========================================
- Hits 25595 25575 -20
- Misses 872 895 +23
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
| proc.join(10) | ||
| self.nn(proc.exitcode) | ||
| slab.initdb('foo') | ||
| self.true(True) |
There was a problem hiding this comment.
is this just testing that the code doesn't go boom?
There was a problem hiding this comment.
Patch coverage of 100% seems to indicate that it covers triggering the actual resize, right?
There was a problem hiding this comment.
This tests that the previous line didn't hit an exception (which it did before the change).
There was a problem hiding this comment.
(It is redundant, but I know you like the explicitness)
|
Added patches to increase the timeout for the Spawn stormpkg test and a patch from Neomorph for a teardown race on the Slab when we delete the environment. |
Previously, if a main process' slab mapsize increases, any existing spawn processes (which have the same slabs open readonly) would get a lmdb.MapResizedError when calling slab.initdb.
Now, initdb correctly handles that case.