[gpgme] fork() problem
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
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