thread support in GPGME (was: Re: Bug in gpgme 0.4.2?)

[Marcus Brinkmann]

On Fri, Aug 22, 2003 at 01:45:39PM +0200, Albrecht Dre? wrote:
> Am 20.08.03 22:59 schrieb(en) Marcus Brinkmann:
> >What is still missing is support for that in gpgme-config, which will get
> >a
> >new option --thread= to select the thread package, and new autoconf
> 
> That should be a usable implementation for balsa, as the config script 
> knows if threads should be used or not...

Yeah, in general the application this is finally linked to its
libraries will know if it wants thread support or not.
 
> >would have to download, compile, install, and maintain.  We thought long
> >about it, and eventually decided that wasting a bit of disk space is
> >better than wasting a lot of man power, so this is what we are doing now.
> 
> Sounds complicated. Did you think about a new function like 
> "gpgme_init_threads({"pthread"|"pth"|...})" to trigger the thread 
> initialisation? Maybe that's easier to maintain...

Yes, we considered that, but what do you do if you have a library
using GPGME?  Then you'd have to export the interface to give the user
of that library a choice.

It would also not eliminate the link order problem using libtool.

In the end, even the current solution is not ideal in the case of a library using GPGME, as such a library needs to make a decision to which of the GPGME
variants it wants to be linked to!  And this is sort of problematic,
but I don't really know a solution, except to provide several variants of that library if necessary.

Also please note that you can not freely mix threaded and non-threaded
code, at least not in GNU/Linux based systems.  libpthread overrides
functions like fork, and that can cause spurious failures (like, for
example, if you have a single-threaded apache and link it with a
threaded mod_python).

We can only hope that eventually all applications will always link to
pthread, and no other thread system exists that people want to use :)
 
Thanks,
Marcus