[gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483)

Read-only notification of GnuTLS library development activities gnutls-devel at lists.gnutls.org
Tue Nov 2 18:03:19 CET 2021




Alexander Sosedkin commented on a discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_721370433

>  			 * allow it to be updated without restarting
>  			 * all applications
>  			 */
> +			GNUTLS_STATIC_MUTEX_LOCK(system_wide_config_mutex);
>  			_gnutls_update_system_priorities();

Not necessarily? The current guarantee is "load a config no older than the moment we invoke the function", what would that change upgrade it to?

I'd propose (getting progressively more frivolous with pseudocode):

```
stat(&mtime);
rdlock();
if (init_indicator && mtime == last_mtime) { unlock(); return; }
wrlock();
if (mtime == last_mtime) { unlock(); return; } // other thread beat us to loading with the same mtime
...
last_mtime = mtime;
unlock();
```

which is a middle-ground that'd still catch some updates during mass-waiting (just not the ones that happened after the last updater was started), yet stick to a single stat call.

All this talk makes me wonder what software does and does not actually bother with atomically replacing gnutls system configs =)

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_721370433
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/20211102/93898213/attachment.html>


More information about the Gnutls-devel mailing list