GPGME: double fork...

[Werner Koch]

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


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170126/6e6a8b02/attachment.sig>