https://bugs.openldap.org/show_bug.cgi?id=9278
--- Comment #5 from Xin Li <[email protected]> --- (In reply to Howard Chu from comment #4) > (In reply to Xin Li from comment #3) > > Created attachment 738 [details] > > Proposed patch > > > > Oops, yes you are right and I clearly have some misunderstanding of the code > > here, sorry for the noise. > > > > Here is a different proposal, basically, it would destroy the robust mutex > > if we are the only remaining user. My understanding of > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02. > > html#tag_15_09_09 was that the effect after unmapping of the mutex object is > > undefined, on FreeBSD, it seems to confuse the threading library because > > after the last mmap is gone, the kernel GC's the object, while it's still on > > userland threading library's bookkeeping ( > > https://svnweb.freebsd.org/base/head/lib/libthr/thread/thr_pshared. > > c?annotate=297141#l220 ) if they are not destroyed. > > Last time I checked, FreeBSD didn't even support robust process shared > mutexes. > What OS revision is required for this to be supported? The support of robust mutexes was added in FreeBSD r300043 (May 17, 2016) and is supported by all currently supported FreeBSD releases (11.3, 11.4 and 12.1). The first release with robust mutex support was FreeBSD 11.0-RELEASE (October 2016). > It seems to me that doing what this test program is doing is a misuse of the > API, you should only ever open an environment once in any particular > process. Closing it and then opening it again makes no sense. Without cleaning up the mutex before unmapping, lmdb will leave the recorded mutex behind and the current code will not be able to recover from that (unlike in the case the calling process crashed, the code would correctly recover from the situation). Since lmdb is performing similar cleanups for semaphores, destroying the mutexes when we are the last user of the database seems to be the right thing to do in my opinion. -- You are receiving this mail because: You are on the CC list for the issue.
