libgcrypt 1.1.93 released

[Nikos Mavroyanopoulos]

On Tue, Mar 09, 2004 at 07:46:30PM +0100, Marcus Brinkmann wrote:

> > The current approach (1.1.93) makes all of the multithreaded applications 
> > using gnutls crash, that's why i'm most concerned about this.
> Maybe some additional data will help with the decision here.
> On my system, I have 86 binaries using gnutls (directly or indirectly).
> Of these, 81 already link to pthread.
> Only five do not link to pthread.  These are cupsdoprint, dirmngr,
> lynx, mailq, and newaliases.
> This is like I expected it.  Many programs these days require pthread
> anyway.
> If this is similar to the whole picture, I don't see much difficulties
> in making gnutls require pthread by default, and optionally build a
> non-threaded version for those who really want it (gnutls-nothread).

This would require other libraries that now rely on gnutls to do
the same. That is modify the cupsys libraries to have a cupsys-thread
and nonthread (and possibly one for the pth), the ldap libraries
as well and several others depending on them. 
I don't think that they'll ever go in to that trouble. They'll probably 
revert to openssl and let us go (I would do that).


> We know that this is not the ideal solution.  As I said in one of my
> last mails, the perfect solution doesn't seem to exist.

In my opinion libgcrypt should be reentrant without knowing the
application's threading method. If this is not possible and
if locking in libgcrypt is here to stay, then
callback locking[0] is much better than the current solution
since only a single library is involved. I know that the drawback
is that two applications, that use different threading methods, when
linked together could not insert both callbacks.
But this is a very rare situation, actually i've never seen such thing happen.


[0]. that is what openssl does currently.

> Thanks,
> Marcus

-- 
Nikos Mavroyanopoulos