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