[gpgme] fork() problem

[Stephan Menzel]

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

Indeed.

> 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
> idea.

Yes.

> 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 
time.

> 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.

Greetings...

Stephan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20070220/e316e443/attachment.pgp