Still problems with GPGME with multithread

Tue Apr 1 20:17:18 CEST 2003

On Tue, Apr 01, 2003 at 01:04:04AM +0200, Laurent Cheylus wrote:
> I am working with Albrecht Dress on GPG support for Balsa MUA (see his
> message on gnupg-devel list posted the 03/03/27).

> I test to modify the link order ('-lpthread' before '-lgpgme' at
> compilation) as described in a precedent thread (Albrecht's solution).
> But for me, it doesn't solve the issue :-(

What a pity.

> Can you help to solve this problem or give some clues to do a better
> analysis of this bug ?

My reply to Albrecht's first mail contained several such hints.  Here they
are again:

There are many pitfalls in GPGME which made it a bit difficult to get
it thread safe, but the ground work is done.  Luckily, the problem you are
actually experiencing does not seem to be related to some of the more
complex aspects in GPGME.

_gpgme_get_program_version is a simple function, basically calling fork (),
exec () to run gpg --version through a pipe and reading from the pipe to
determine the version number.  That the read() hangs can mean one of two
things:

1. There is no data written to the pipe.  That would mean gpg doesn't
actually run, and you should follow the child to see what's going wrong.
A simple check would be to see if gpg --version does run (and if, if it is
hanging or not).  This might be difficult because of the timing.  But you
could replace /usr/bin/gpg with a wrapper to get more info.

2. The read is actually hanging.  This would mean that there is some issue
in glibc that causes this.

You could also try writing a small test case that I can add to the source.
It would make it easy for me to take a closer look at this.

Thanks,
Marcus

--
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus at gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann at ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/