[gnutls-devel] Automatic library initialization
tim.ruehsen at gmx.de
Mon Nov 16 11:02:48 CET 2015
after thinking a bit, ... having GNUTLS_NO_EXPLICIT_INIT is nice, but does not
solve my issue.
We are in a world of mixed plain-text and TLS connections. The library doesn't
know what will be requested (TLS or plain text) - but it rushes ahead and does
a heavyweight initialization in any case. This is IMO a bad idea (think of
'Green IT', embedded devices, low power apps, etc).
I recognize the additional CPU usage when tuning my projects to less CPU
utilization. Dynamic loading GnuTLS doesn't make sense right now. Tuning any
other code doesn't make sense (GnuTLS load factor of ~60 in comparison to the
rest of the code).
IMO, you should revert your decision and should not automatic initialize. For
someone who badly needs that (beyond my imagination right now), a ./configure
flag and GNUTLS_NO_EXPLICIT_INIT should do it. Maybe it should be
GNUTLS_AUTOMATIC_INIT, defaulting to 0.
Just my thoughts.
On Monday 16 November 2015 10:36:41 Tim Ruehsen wrote:
> On Wednesday 11 November 2015 11:33:32 Nikos Mavrogiannopoulos wrote:
> > On Tue, Nov 10, 2015 at 4:23 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> > > Hi,
> > >
> > > an executable, dynamically linked with GnuTLS, automatically calls
> > > gnutls_global_init(). And thus (in my case) eats up 60x more CPU cycles
> > > than needed.
> > > The executable only needs GnuTLS under some conditions (TLS connection
> > > requested). In this case it 'manually' calls gnutls_global_init().
> > There is the undocumented env variable GNUTLS_NO_EXPLICIT_INIT. If you
> > set it to 1 you disable the use of constructor and destructors to load
> > gnutls.
> Hi Nikos,
> this variable does not exist in 3_3_x branch. In 3_4_x it is documented.
> Bad luck for me :-(, Debian still uses 3.3.x.
> Could you backport it to 3.3 (commit 205ad24f and 9b43ac82) ?
> Regards, Tim
> Gnutls-devel mailing list
> Gnutls-devel at lists.gnutls.org
More information about the Gnutls-devel