libgcrypt 1.1.93 released

[Nikos Mavroyanopoulos]

On Wed, Mar 10, 2004 at 11:29:20AM +0100, Marcus Brinkmann 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?

I don't know how applications that do not use the pthread would behave, as you 
said this may have side effects.

> > 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.
I think (correct me if i'm wrong) that those libraries 
do not use nor require pthreads, so they wouldn't bother to set any callback
lock. I've rarely seen libraries that use threads, so it wouldn't do any harm[0]. 
In most cases the callback will be used by the multithreaded application that 
uses those libraries.

[0]. even if this was the case the threading model, of the library and
the application, most probably would be the same so it wouldn't matter 
who sets the callback locks.

> 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! 

> Thanks,
> Marcus

-- 
Nikos Mavroyanopoulos