From: Zbigniew Jędrzejewski-Szmek Date: Fri, 3 Oct 2025 11:17:32 +0000 (+0200) Subject: man: fix advice regarding thread safety of libsystemd X-Git-Tag: v259-rc1~385 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=4a3620c55a83317dc397f840bffe445a2ab1c038;p=thirdparty%2Fsystemd.git man: fix advice regarding thread safety of libsystemd The prohibition to move libsystemd objects between threads was added in 64a7ef8bc06b5dcfcd9f99ea10a43bde75c4370f ('man: be more explicit about thread safety of sd_journal'). At the time, this was valid, because we were using the mempool for allocation and it apparently didn't handle access from different threads. Sadlly, the commit links to a bugzilla entry referenced in the commit is not publicly visible anymore, so the details are murky. But we stopped using the mempool in a5d8835c78112206bbf0812dd4cb471f803bfe88 ('mempool: only enable mempool use when linked to libsystemd-shared.so'), with subsequent followup in b01f31954f1c7c4601925173ae2638b572224e9a ('Turn mempool_enabled() into a weak symbol'). The restriction added in the man page is not necessary since then. The text in the man page was arguably incorrect in calling the code "thread-agnostic". If the code does not support being touched from threads at all and has global state to tied to the main thread, it is not "agnostic", but just doesn't support threads. (I'm looking into https://github.com/systemd/python-systemd/issues/143, and with the current scheme, the python-systemd module and all python code using libsystemd would be very hard to use. With the change to free-threaded python in python3.13, i.e. the replacement of single Global Interpreter Lock by locking on individual objects, this limitation would become even more constraining.) --- diff --git a/man/sd-journal.xml b/man/sd-journal.xml index 6fc18e71e37..da4e4e1f823 100644 --- a/man/sd-journal.xml +++ b/man/sd-journal.xml @@ -75,13 +75,14 @@ Thread safety - Functions that operate on sd_journal objects are thread agnostic — given - sd_journal pointer may only be used from one specific thread at all times (and it has to - be the very same one during the entire lifetime of the object), but multiple, independent threads may use multiple, - independent objects safely. Other functions — those that are used to send entries to the journal, like - sd_journal_print3 and similar, - or those that are used to retrieve global information like - sd_journal_stream_fd3 and + Functions that operate on sd_journal objects are thread agnostic — a given + sd_journal pointer may only be used from one thread at a time, but multiple + independent threads may use multiple objects concurrently. Some functions — those that are used to send + entries to the journal, like + sd_journal_print3 and + similar, or those that are used to retrieve global information like + sd_journal_stream_fd3 + and sd_journal_get_catalog_for_message_id3 — are fully thread-safe and may be called from multiple threads in parallel. diff --git a/man/sd_journal_get_catalog.xml b/man/sd_journal_get_catalog.xml index 56acabb441b..187f7ef77c8 100644 --- a/man/sd_journal_get_catalog.xml +++ b/man/sd_journal_get_catalog.xml @@ -84,14 +84,12 @@ Notes - Function sd_journal_get_catalog() is thread-agnostic and only - a single specific thread may operate on a given object during its entire lifetime. It is safe to allocate multiple - independent objects and use each from a specific thread in parallel. However, it is not safe to allocate such an - object in one thread, and operate or free it from any other, even if locking is used to ensure these threads do not - operate on it at the very same time. - - Function sd_journal_get_catalog_for_message_id() is are thread-safe and may be called in - parallel from multiple threads. + Function sd_journal_get_catalog() is thread-agnostic and only a single thread + may operate on a given object at any given time. Multiple independent objects may be used from different + threads in parallel. + + Function sd_journal_get_catalog_for_message_id() is thread-safe and may be + called from multiple threads in parallel. diff --git a/man/threads-aware.xml b/man/threads-aware.xml index 8492ca398f9..05e7514f433 100644 --- a/man/threads-aware.xml +++ b/man/threads-aware.xml @@ -6,10 +6,9 @@ - <para id="strict">All functions listed here are thread-agnostic and only a single specific thread may operate on a - given object during its entire lifetime. It is safe to allocate multiple independent objects and use each from a - specific thread in parallel. However, it is not safe to allocate such an object in one thread, and operate or free it - from any other, even if locking is used to ensure these threads do not operate on it at the very same time.</para> + <para id="strict">All functions listed here are thread-agnostic and only a single thread may operate on a + given object at any given time. Different threads may access the same object at different times. Multiple + independent objects may be used from different threads in parallel.</para> <para id="safe">All functions listed here are thread-safe and may be called in parallel from multiple threads.</para>