https://bugs.openldap.org/show_bug.cgi?id=9920
--- Comment #22 from kero renault.cle@gmail.com --- Hey Niko,
I just looked into your `lmdb-crypto-rs` library, which is a very old library that I completely rewrote. It's indeed the original design done by the Mozilla team. Using traits, not range implementation, and not types is complex. I now use heed, and the design is much easier to understand and work with.
I don't think I will have the time to rewrite the redb benchmarks with this library, but if you want, you can try to use `lmdb-crypto-rs` on my fork[1].
Maybe there is also an issue with your rust wrapper, that adds even more instability to your tests.
Yup, maybe. But as I stated before, it works perfectly with the LMDB@0.9 version (heed itself). It doesn't mean much, but I did not share `RwTxn` between threads (!Sync + Send), and `RoTxn`s are also non-referenceable and non-moveable between threads (!Sync + !Send).
As you can see in this multi-threaded example[2] (db corresponds to a lmdb::Env in this context), the read transaction is created directly in the spawned thread and dropped (abort) at the end of it. There may be something wrong with sharing an env between threads, but it was never something in LMDB@0.9.
Just to be sure that I wasn't missing something, I re-read the documentation (that I hope is up-to-date) of mdb.master3, and there is nothing special about sharing envs between threads, and the same restriction as on mdb.master applies to the RoTxn and RwTxn. Also, I tried running the redb benchmarks with the MDB_NOTLS flag, and it corrupted the db similarly.
[1]: https://github.com/Kerollmops/redb/pull/1 [2]: https://github.com/Kerollmops/redb/blob/c93a74ab8da0a09c56ee68ec4f6a495f7851...