Re: (ITS#8505) LMDB vs. fork()

[h.b.furuseth@usit.uio.no]

On 28/09/16 21:29, lmb@cloudflare.com wrote:
> I think your proposal is going beyond what I was trying to do.

Yes. Your concern seems to reduce to a doc bug and an otherwise- 
harmless file descriptor leak which it is too late to fix
completely. So I ended up thinking of resource leaks in general.

> From the documentation, it sounds like a process using LMDB can not
> safely fork, under any circumstances. My idea was to specialise this
> to saying that fork() followed immediately by exec() is safe,

Yes.  That doc bug should be fixed.

> but that
> a plain fork() is still not supported.  If a child wants to use the
> same db, it goes through the regular mdb_env_open sequence, rather
> than somehow inheriting the environment across the fork.  I think that
> should address your pthread_exit concern, as well?

It'd be pretty intrusive of a _library_ to forbid the user to
fork() at all without exec().  A _program_ could specify that.
So I prefer to protect the parent from pthread_exit in the child.
(Note, this has nothing to do with file descriptor leaks).

> On your point that a user may not call mdb_env_close before the fork:
> the user might not want to, since s/he still wants to use the env in
> the original process.

No, I mean a partial env_close to be called _after_ the fork, in the
child.  A child which does not want FD-leaks must in any case do a
close() loop or close the mdb_env_get_fd() descriptor. So maybe we
just as well should give him a more thorough "free resources in child"
call which cleans up a bit for exec()-less programs as well.
(It'll need an argument which says just what is safe to clean up -
e.g. it can't do much much if the parent is already multi-threaded.)