GPGME CVS branched

[Simon Josefsson]

Marcus Brinkmann <marcus.brinkmann at ruhr-uni-bochum.de> writes:

> In the future, I think I will change GPGME's threading support to be
> like gcrypt, so you install callbacks.

I'm not sure I like this approach in gcrypt, so I'd like to ask
exactly why are you considering this?

I find that requiring threaded applications to provide thread hooks
into libraries is problematic.  The most common situation where a this
causes problems is when a threaded application uses one library that
in turn uses gcrypt/gpgme.  The middle-library does not need thread
hooks, so it does not provide any functions for the application to set
them, and consequently does not set them any thread hooks in gcrypt.
The application may use several libraries that look like this (e.g.,
gnutls and gsasl), so gcrypt may end up being invoked in multiple
threads with no thread hooks.

Requiring the application to be notice that gnutls/gsasl uses gcrypt,
and have the application call the thread hooks in gcrypt, destroy
abstraction layers.

Forcing all libraries that use gcrypt to also provide thread hooks
also does not look like a scalable solution to me.  In a big
application, different parts may use different thread implementations.
E.g., the top-level application might use Pth, but some lower-level
library can be written for the specific platform, and could use POSIX
threads, or even NPTL.

I reviewed all uses of thread hooks in libgcrypt (a lot!), and to me
all of the uses could be avoided by choosing a simpler design.
Compare Nettle.  Perhaps the only exception I could find was
randomness gathering, but then again I think that is such a critical
function that the complexity of thread interaction should be avoided
at all.

I wish there were a paper that collected common wisdom about writing
libraries that are used in multi-threaded applications, but I haven't
seen any that discuss these issues in any detail.  I'm imagining
something like Ulrich Drepper's excellent paper about writing and
maintaining shared libraries.

Thanks,
Simon