making gnutls depended to pthread

[Nikos Mavrogiannopoulos]

>> Hello,
>>  I've been thinking it for quite some time but given the bug report:
>> https://savannah.gnu.org/support/?107409 , I think it might be relevant.
>> GnuTLS due to its use of random numbers will always need a global pool
>> to be accessed, and thus locking is mandatory. How about making a new
>> gnutls_global_init2() that accept flags such as USE_SYSTEM_LOCKS (that
>> would be pthread for linux), by default? This way gnutls will initialize
>> all libraries that it is depended on using the default threads for each
>> system.
> I don't want to see GnuTLS require pthreads, as pthreads doesn't exist
> on several platforms (e.g., Windows).

This is why I proposed using the native system thread system. Windows
will have their own locks.

> Even on GNU/Linux I'm not sure pthreads is universal, I think both GNU
> Pth and NPTL is still in wide use.

Isn't NPTL the actual pthreads in linux? GNU Pth is a userspace
implementation of threads, a practice used in the late 80's and 90's
but I doubt today anyone is using it.

> So I think a flag USE_SYSTEM_LOCKS flag would be confusing, as it isn't
> clear what the application is getting -- one library may be using the
> system's NPTL library and another library may be using the system
> -lpthread and a third library may use GNU Pth, and if the all are linked
> into one application, things will break badly.

Things break badly with the current API as well with the scenario you
describe. I don't think there a practical way even to mix this kind of
libraries. 99% multithreaded of the applications in linux use
pthreads, thus it is safe to assume a default for them, and allow the
1% that does use something different to use their own hooks. Currently
every application that uses threads has to register locks with the
same code as if it was exceptional use. Moreover the issue described
in the savanah bug report occurs even if libraries and applications
use pthreads only.

> Doesn't a gnutls_global_set_mutex-approach where the caller provides the
> mutex functions solve this problem?

I update my point. To have such a function but provide defaults if it
is not called. My idea is for systems with pthreads to provide
pthreads as default and for windows to provide the critical section
locking code as defaults. Applications using exotic thread
implementations can still use gnutls if the use the function you
describe. This should solve the issue at
https://savannah.gnu.org/support/?107409

regards,
Nikos