On 22/08/16 12:47, Lorenz Bauer wrote:
The LMDB documentation says the following in its section on caveats:
- Use an MDB_env* in the process which opened it, without fork()ing.
- Do not have open an LMDB database twice in the same process at the same time. Not even from a plain open() call - close()ing it breaks flock() advisory locking.
This seems contrary to an earlier thread on this list (1), which suggests that fork/execing a process using LMDB is OK so long as the MDB_env is not used in the forked process.
It's just poorly worded. The point of the first sentence is, "do not use the MDB_env after forking". It's OK to fork if you do not use it afterwards. A patch with a better wording might be in order:-)
Also I'm guessing that restriction is only relevant on Unix: Hopefully Windows locking doesn't have flock's insane semantics. I don't know Windows though.
(...)
- Seems like there is currently no call to SetHandleInformation with
HANDLE_FLAG_INHERIT=0 for Winows, should that be added?
MDB was originally written with Unix in mind. I'm guessing the "no multiple handles" restriction is only relevant on Unix: Hopefully Windows locking doesn't have flock's insane semantics. But I don't know Windows.
OTOH it won't hurt to add close-on-fork/exec flags for everything, not just the Unix lockfile descriptor. Would need to factor the opens out to a separate function to avoid excessive code and #ifdef duplication, I never got around to it. (Or rather, I drafted something but it got complicated and I didn't want to spend time testing it on Windows.)
Regarding your next message:
The unix version only uses O_DIRECT if psize >= OS psize because O_DIRECT typically requires alignment on OS page boundaries, or something like that. Should be commented. Didn't find anything similar in the Windows doc, but again, I don't know Windows. Maybe Howard knows more.