[Date Prev][Date Next]
Re: (ITS#7377) Poor libmdb error handling
Howard Chu 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.