[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
Mon Nov 1 18:48:45 CET 2021
Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1483 was reviewed by Alexander Sosedkin
--
Alexander Sosedkin started a new discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_720200779
> */
> + GNUTLS_STATIC_MUTEX_LOCK(system_wide_config_mutex);
> _gnutls_update_system_priorities();
I don't understand in general: why have it inside the loop and not before it? It's not like there the loop duration is meaningfully long, and then if somebody manages to update the config in-between reloadings, I'm not sure I prefer switching to a new version mid-loop.
--
Alexander Sosedkin started a new discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_720200785
> #include <priority_options.h>
>
> +/* Lock for reading and updating the following global variables prefixed with
Is it time to group them into a struct? If we aim for consistency between reading/updating them as a group, that could make it more explicit.
--
Alexander Sosedkin started a new discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_720200789
> + /* This requires a lock so there are no inconsistencies in system_wide_*
> + * loaded from the config file. */
> + GNUTLS_STATIC_MUTEX_LOCK(system_wide_config_mutex);
Mild: I'd prefer locking inside the function or in an extra wrapper around it if it's inconvenient to overhaul its flow.
--
Alexander Sosedkin started a new discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_720200794
> void _gnutls_unload_system_priorities(void)
We deliberately don't lock in this one or `_clear_default_system_priority` because ensuring thread safety is on the caller of `gnutls_global_deinit`, right?
--
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483
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/20211101/49386fa5/attachment.html>
More information about the Gnutls-devel
mailing list