[gpgme] fork() problem
smenzel at gmx-gmbh.de
Tue Feb 20 16:51:27 CET 2007
Am Dienstag, 20. Februar 2007 15:09:56 schrieb Marcus Brinkmann:
> 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.
Well, the concurrency we are doing in the daemon in question is mostly done by
pthread mutexes and boost mutexes (which are pthread* implemented as well as
far as I know)
The daemon itself didn't have any problems with it's concurrency at this point
before I used those calls even though it's running at very heavy load,
without leaking mem btw. on several hundred machines so I take the liberty
and assume it's concurrency is implemented reasonably stable at this stage.
> First, I think you are jumping to conclusions, which is always a bad
> 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.
Well, If I can provide any more, just ask. I gave everything I had and
everything I know about this. It was just too rare to be provoked.
> 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."
Well, thank bob it didn't go away by itself. I just moved it out of the area
where it would be problematic into a seperate daemon where it's not too much
of an issue if a process would crash from time to time. Which didn't happen
so far btw. But it's a forking daemon rather than a threaded one.
> 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).
Well, that would be a nice option too. If I could communicate with such a
service via Domain Sockets (or TCP) I would be in control of any blocking
> 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.
Well, it is mysterious indeed: Perhaps it was just some kind of a load
situation gpgme is not experiencing very often.
But as I said, If I can provide any help accumulating further information, I'd
be glad to help.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20070220/e316e443/attachment.pgp
More information about the Gnupg-devel