[gnutls-dev] Re: living without global variables

[Simon Josefsson]

bryanh at giraffe-data.com (Bryan Henderson) writes:

>>The distinction between a library and an application is rather blurry
>>nowadays.
>
> Yes, lets just say that a program consists of multiple modules, and some
> of them are related in a hierarchical way -- A uses B, B uses C.  Some
> modules are packaged as code libraries.  One module stands out, because
> it is at the top of the hierarchy -- the thing that gets control first
> and controls, at least indirectly, every other module.
>
>>I'm not convinced it scale to force applications to initialize all
>>libraries -- i.e., to force OpenOffice to initialize libgcrypt because
>>OpenOffice may use some component that eventually may dlopen some
>>library that may use gnutls that may use libgcrypt.
>>
>>I'd rather have libraries initialize the libraries they use
>>internally, to make things modular.
>
> If you take dlopen out of the picture for the sake of analysis, you
> can have both.  OpenOffice initializes the component that it uses
> directly, which initializes another library, which initializes gnutls,
> which initializes libgcrypt.  So the top level module (OpenOffice)
> effectively initializes libgcrypt, without ever knowing that libgcrypt
> exists.  If you believe that libgcrypt should be participating in the
> program's threading, then you also believe that all those other layers
> should too, and therefore the "threading model" information is present
> in parameters on all of their initialization routines.

I think we are saying the same thing in different ways.

The problem with libgcrypt is that gnutls cannot initialize it
correctly, because libgcrypt need to know about threads, of which
gnutls know nothing.  The "solution" is to require that OpenOffice
initialize libgcrypt if it uses some library that uses gnutls.  I
don't think that approach scale.  I believe the approach you outline
is better.  I do not think all libraries need to participate in the
threading, most libraries do not use threads so it is irrelevant to
them.  Adding thread initialization code just because the library uses
libgcrypt seem wrong to me.

We will need a cleaner solution to this.  The remaining problem with
the gnulib approach is to add APIs for MPI, and to solve the RNG
situation.  Help welcome.

Thanks,
Simon