[gpgme] fork() problem

Marcus Brinkmann marcus.brinkmann at ruhr-uni-bochum.de
Tue Feb 20 15:09:56 CET 2007

At Mon, 19 Feb 2007 19:57:52 +0100,
Stephan Menzel <smenzel at gmx-gmbh.de> wrote:
> [1  <multipart/signed (7bit)>]
> [1.1  <text/plain; iso-8859-1 (quoted-printable)>]
> Am Montag, 19. Februar 2007 16:01:12 schrieb Stephan Menzel:
> > I think I've got it solved. I just took the functionality and moved it away
> > out of the daemon and put it into a new daemon that doesn't use threading
> > but rather uses fork() itself.
> ...and just one little addition to this: I did some research on the subject 
> and questioned some collegues and it turned out some of them have the strong 
> opinion that forking around in a heavyly multithreaded process is evil[tm] in 
> itself and should be avoided at all costs.

This is advice of mixed quality: It's good advice in the sense that it
is better to avoid a feature than use it without thorough
understanding of the issues.  But one should always be open to
exploring new territory, even if it looks dangerous :)

Concurrency is difficult to begin with.  It's a good idea to stick to
one model of concurrency, threads or forks.  But the fork() calls that
happen in GPGME are really fancy _posix_spawn() calls, not forks, and
_posix_spawn() is reasonably harmless even in multi-threaded applications.

> This might just be a rumour but I don't think so. Do you think it would be 
> feasible to do the job without forking another process? Do do the job inside 
> the lib? I think that would enhance gpgme's usability for use cases such as 
> mine.

First, I think you are jumping to conclusions, which is always a bad
idea.  Let's face it: At this point we have not the slightest idea
what was going on when you encountered the problems.  The descriptions
you gave where by no means sufficient to make a diagnosis, so we just
don't know where the problem was.  Now you found a work-around that
avoids the problem altogether, which is fine if it works for you,
although I am a believer in the saying: "Problems that go away by
themselves come back by themselves."

To answer your question: In some ways, GPG moves towards running as a
daemon already.  It may be feasible in the future to avoid the fork()
in some situations and replace it with connecting to a socket (in
fact, for GPGSM you could do this with a little work on GPGSM and
GPGME already).  But this has nothing to do with extending use cases.
For all I know, GPGME supports your use case perfectly fine, and we
can only file your error report under "mysterious" until further
information is accumulated.


More information about the Gnupg-devel mailing list