You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It makes sense that the env and txn classes are moveable but not copyable, since they represent resources that are closed on destruction. But dbi isn't like that — the destructor is a no-op. So I don't see a reason for not having a copy constructor and copying assignment.
Having these would make it cleaner to pass dbi instances as parameters, store them in member variables, etc.
The text was updated successfully, but these errors were encountered:
I think this issue makes the library hard to use in a multithreaded environment. The documentation for lmdb says of mdb_dbi_open, "After a successful commit the handle will reside in the shared environment, and may be used by other transactions." It also says, "This function must not be called from multiple concurrent transactions in the same process."
Together, I take it to mean that the main process should open a database once (inside a transaction) and then pass the dbi handle to each of the threads it spawns. Without being able to copy an lmdb::dbi, I think the only way to do this is to pass the underlying handle around.
In my fork of this library (https://github.com/hoytech/lmdbxx) I have made lmdb::dbi instances copyable. I can't think of any situation where copying the dbi would cause a bug, and in many cases being able to copy dbis or pass them by value simplifies application code.
It makes sense that the
env
andtxn
classes are moveable but not copyable, since they represent resources that are closed on destruction. Butdbi
isn't like that — the destructor is a no-op. So I don't see a reason for not having a copy constructor and copying assignment.Having these would make it cleaner to pass
dbi
instances as parameters, store them in member variables, etc.The text was updated successfully, but these errors were encountered: