Howard Chu wrote:

h.b.furuseth@usit.uio.no wrote:

...

Maybe add a flag to request error paranoia, like setting PTHREAD_MUTEX_ERRORCHECK. Trying to catch if a current mdb process has lost is locks. (The fcntl F_SETLK is lost if the process closes another file descriptor to the same file, e.g. after some other module in the process opened and closed the mdb lock file.) Catching a change to the pid from getpid().

That's really not interesting to me. No other module has any business opening and reading our lock file.

I skipped a step there. The other module could also be using mdb. "other module" = "a program component which the module using this MDB_env does not know about". They may even be linking different libmdb.so's, so the 'libmdb's can't notify each other via static vars. There are a few other use cases like a monolith program which also can backup a directory - which the user could point at the mdb dir.

Anyway, a CAVEATS section in the doc is the obvious fix.

We haven't bothered with this for alock either, and it hasn't been a problem.

Note that this ITS is about libmdb, not back-mdb.

...

The fork() restriction needs to be documented, as does "don't open or close the same database twice in the same process".

Go ahead.

Hmm. I suggested a too pessimistic caveats section once, I can dig that up and try again.