libgcrypt 1.1.93 released

[Marcus Brinkmann]

At Wed, 10 Mar 2004 09:22:49 +0200,
Nikos Mavroyanopoulos wrote:
> > 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).

What about just requiring pthread?
 
> > 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.

And who sets the callbacks?  I don't really see how you can do that
without adding a set_locking_callback interface to each and every
library that is involved.  If that is "standard" in that those
libraries like cupsys and ldap etc already have such locking
interfaces, I'd be more than fine with such a solution.

If all those other libraries are going to simply set these callbacks
to the pthread interface anyway, I don't see a very strong reason why
you shouldn't require pthread in gnutls, too.

OTOH, I do see your point here.  It would cost us little to provide
such callback locking (and I/O) on top of the current model, and it is
a sane extension.  We can let both solutions stay in parallel and see
what people use.  In fact, it even makes a moderate amount of sense to
have such a callback interface.

So, I guess you have convinced me here.

Thanks,
Marcus