[gnutls-devel] GnuTLS | Thread local storages not free'd until application exits (#824)
Development of GNU's TLS library
gnutls-devel at lists.gnutls.org
Fri Sep 6 10:29:57 CEST 2019
Dave Craig commented:
> The fix you propose look reasonable to me. Why do you think it would be no benefit?
Well it does work, and in the cold light of day doesn't look so bad. I guess the trade off for us was whether there was much benefit to us of using TLS at all vs. backing out the change to TLS. I was probably confusing my own short term goals with what the best fix overall was. It was only getting called every couple of seconds, and so it's speed performance isn't that important.
> Is it for this particular application with short-lived threads?
I was slightly surprised at the GStreamer behaviour. It's re-using threads from a thread pool, but I guess the thread is being reset in some way, because with my pthreads TLS implementation I could see the storage being created and destroyed almost (but not quite) every call. That obviously makes using TLS less useful for this application.
> An other solution would be to be re-using these areas, but I haven't really investigated how easy
> or reasonable that is.
If TLS has an advantage for some users, then keeping it as it is but with added destructor handling as in random.pthread_tls.c would seem the best approach. A colleague had suggested waiting for C11 threads.h support (which we had coming soon), but perhaps pthreads is still the approach with the widest coverage.
--
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/824#note_213402807
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20190906/00e75f56/attachment.html>
More information about the Gnutls-devel
mailing list