-
istruewing@chilla.local authored
The previous two patches for this bug worked together so that no permanent table was memory mapped. The first patch tried to avoid mapping while a table is in use. It allowed mapping only if there was exactly one lock on the table, assuming that the calling thread owned it. During mi_open(), a different call to memory mapping was coded, which did not have this limitation. The second patch tried to remove the code duplication and just called mi_extra() from mi_open() an thus inherited the limitation. But on open, a thread does not have a lock on the table... A possible solution would be to check for zero or one lock. But since I learned that it is safe to memory map a file while normal file I/O is done on it, I removed the restriction altogether and allow to memory map while a table is in use. No test case. I do not see a chance to verify with the test suite which kind of I/O is used on a table.
67d97254