GPGME: double fork...
wk at gnupg.org
Thu Jan 26 18:40:55 CET 2017
On Thu, 26 Jan 2017 02:23, gniibe at fsij.org said:
> GPGME can be used with Pthreads. Users may use pthread_atfork to
> clean up things at fork.
Moving the atfork callback before the second fork seems is a good idea.
Using vfork is questionable because of the weird semantics of vfork -
with any modern system there should be no penalty between fork and
vfork. Using vfork as a way to smart out pthread_atfork may bring more
trouble than it solves.
> Unfortunately with Pthreads, there is no way to pop the ATFORK callback.
> So, the callback added by pthread_atfork was called twice by the double
Such callbacks are anyway very fragile constructs and should be avoided
if anyhow possible.
A real problem we have in gpgme is that some time ago I changed
get_max_fd() to utilize /proc to find the highest fd. That involves
opendir which unfortunately uses malloc which in turn uses a mutex and
may thus create a deadlock between parent and child. In a multithreaded
program we should only use async-safe functions between fork and exec.
For safely reasons we better drop that code. For BSD systems we can
use closefrom to speed up closing of fds - a pitty that this is not
possible on Linux without resorting to running a helper process.
A straightforward solution for both problems would be a helper program
which takes care of closing fds and exec-ing the real program. It is a
bit funny that we had to do that for Windows for related reasons but
recent Windows systems seem to allow to do without a helper.
What about testing a helper approach and run some benchmark (on single
threaded and multithreaded Linux and BSD systems)?
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 227 bytes
Desc: not available
More information about the Gnupg-devel