[gnutls-dev] Re: living without global variables

[Simon Josefsson]

"ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio at vodafone.com> writes:

> Use of atexit is not portable. On many platforms atexit routines get
> call when program terminate. Using in a DSO can lead calling not
> existing code. I did some research in how to handle this but I didn't
> find a portable way to do this... If you detect gcc the better solution
> is to use __attribute__((destructor)) (not easy to check this on
> configure script). 

This sounds bad.  Hopefully other solutions will be suggested that
work better.

>> > On the other hand, in what I propose each thread has its own memory
>> > and there can't possibly be a conflict.  (The synchronization point
>> > moves to malloc(), which is a reliable place for it).
>> 
>> Alternatively, each thread could do a mutex around the call to
>> gnutls_global_init:
>> 
>>  mutex_get()
>>  gnutls_global_init();
>>  mutex_release();
>> 
>> Although I wonder if the complexity is worth it.  The only danger in
>> not doing this is that if there is a thread race, you could leak some
>> memory.
>> 
>
> This do not solve problems if gnutls_global_init is called by two
> libraries using two separate mutexes (assuming library A does not know
> library B you cannot share same mutex).

Right, the function is not thread safe.

>> >>Remember that API changes are bad.
>> >
>> > But API _additions_ are no big deal.  I'm talking about adding three
>> > new functions for people to use optionally in place of 
>> three existing
>> > ones, and people who use the existing ones will see no difference at
>> > all.
>> 
>> Good!
>> 
>
> IMHO with some changes is possible to retain also ABI...

I'm interested in seeing what changes you are thinking of.  To me, it
sounds like a lot of work to rewrite all of GnuTLS to use non-global
ASN.1 structures.  I think it is easier to solve the problem by
letting the caller of gnutls_global_init make sure it isn't called
twice at the same time.

> An easy way to make GnuTLS thread-safe is use mutex directly from
> GnuTLS.

But as you note above, this doesn't work.  If library A use GnuTLS but
doesn't use threads, and library B use GnuTLS but does use threads,
the mutex will be useless.

> The session idea works however it require extra parameters in many
> functions... This has also an advantage. Assuming someone can add
> ciphers or other informations to GnuTLS these informations are not used
> globally but only limited for each session. Also it fix all DSO problems
> cause memory deallocation is demanded to caller, not to GnuTLS. This
> also make it possible to demand thread-safety to caller.

Patches are welcome...

/Simon