Howard Chu wrote: >[email protected] 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.
