[gnutls-dev] Re: living without global variables

[Bryan Henderson]

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

Dlopen throws in extra complexity, but only because of the multithread
problem because dlopen can happen while other threads are running.  Or
can it?  Libraries have loader-level initialization and termination
code -- maybe it's a requirement of dynamic library loading that all
other threads be stopped while the load/unload takes place.  The
dlopen I know is part of the same component as the thread facilities
(GNU libc), so that's a possibility.  Anyone know?

-- 
Bryan Henderson                                    Phone 408-621-2000
San Jose, California