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

[lmb@cloudflare.com]

On 29 September 2016 at 03:39, Hallvard Breien Furuseth
<h.b.furuseth@usit.uio.no> wrote:

> 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.

Why is it harmless in your opinion?

> It'd be pretty intrusive of a _library_ to forbid the user to
> fork() at all without exec().

>From my point of view, that is what the LMDB doc says. I can't use
LMDB and fork(). We're probably approaching this from different angles
though: I want to take something away that is de-facto possible, but
was not documented to be that way.

> 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.)

Sorry, I misunderstood you here.

If I understand you correctly, LMDB would be safe to use in these
scenarios in an ideal world:

1. mdb_env_open(), fork(), exec() (without fd leaks I'd argue)
2. mdb_env_open(), pthread_create(), fork()
3. mdb_env_open(), fork()

As far as I understand you are after 2 and 3, while I want 1. Case 2
seems unlikely, given that forking a multi-threaded program is so hard
that is rarely makes sense [1]. Case 3 is simply a matter of
reordering the calls.

1: http://thorstenball.com/blog/2014/10/13/why-threads-cant-fork/