[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Using LMDB safely with fork() and exec()



Duh - the mdb_env_copy() FD should have FD_CLOEXEC, since the
point was the user can't get at it.  Fixed after an off-list
discussion.  OTOH MDB_env.me_fd should not: mdb_env_get_fd()
exposes it, so CLOEXEC would break existing programs.


Another issue is with fork() without exec().  This breaks LMDB:
   if (fork() == 0) pthread_exit(NULL);
because the child's me_txkey destructor releases the reader slot.

This can happen if a single-threaded LMDB process forks a multi-
threaded child, which is one way to deal with threads vs. fork().

pthread_atfork() is the official way to deal with that.  I'm a bit
wary of it since there is no way to unregister an atfork handler.
I wonder what happens if the LMDB module was dynamically loaded
and then gets unloaded.  A simpler way is in any case to check
if (reader->mr_pid == getpid()) in mdb_env_reader_dest().

I suppose there could be an mdb_env_fork_cleanup() function which
at least closes the FDs, and takes an arg to say whether to free
memory too (safe if parent was single-threaded).