[gpgme] fork() problem

[Marcus Brinkmann]

At Tue, 13 Feb 2007 15:43:56 +0100,
Stephan Menzel <smenzel at gmx-gmbh.de> wrote:
> 
> [1  <multipart/signed (7bit)>]
> [1.1  <text/plain; utf-8 (quoted-printable)>]
> Hi there,
> 
> another not quite simple question I have regarding gpgme is: How exactly does 
> it work? Am I seeing this correctly that it uses fork() to start an external 
> process and communicates with it through pipes?

GPGME does a double-fork to make the engine process a child of init.
After the first fork, it immediately forks a second time (the first
child exits then), the first child exits.  Then it prepares the file
descriptors and execv's.

The parent in the mean while just waits for the first child to exit:
The engine execv proceeds asynchronously, and remaining
synchronization happens via the file descriptors.

This relieves GPGME from doing child management, which would require
signal handling and that's tricky in multi-threaded environments.
 
> And if so, what happens to mutexes in that case. I often heard forking 
> processes with mutexes is always messy and results in strange behaviour. 
> (Stevens, "Unix IPC")

Mutexes are destroyed when the execv happens.  pthread only inherits
the calling thread at fork().  Thus such mutexes *in the child* would
not be released, causing deadlocks *in the child* when you would
continue.  However, nothing in this should affect the parent, and we
execv() almost immediately, so it should not be an issue.

At least that's my understanding of the issue.

So much about GPGME's fork.  However, there is a corresponding issue.
If the GPGME-using application does a fork, not to do an execv but to
do some work, then GPGME's internal mutexes are in a possibly
inconsistent state.  Currently, GPGME does not support this
configuration, in fact, it was never considered by me (an omission).

Do you fork() in your program and then not execv?

Thanks,
Marcus