Re: (ITS#7377) Poor libmdb error handling

[Hallvard B Furuseth <openldap-its@OpenLDAP.org>]

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.