]> git.ipfire.org Git - thirdparty/systemd.git/commitdiff
man: fix advice regarding thread safety of libsystemd
authorZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Fri, 3 Oct 2025 11:17:32 +0000 (13:17 +0200)
committerYu Watanabe <watanabe.yu+github@gmail.com>
Sat, 4 Oct 2025 21:26:47 +0000 (23:26 +0200)
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.)

man/sd-journal.xml
man/sd_journal_get_catalog.xml
man/threads-aware.xml

index 6fc18e71e377604d46ea8d67ad48970c19bb5e2e..da4e4e1f82340d39331819dd05a0b783335f7e4e 100644 (file)
   <refsect1>
     <title>Thread safety</title>
 
-    <para>Functions that operate on <structname>sd_journal</structname> objects are thread agnostic — given
-    <structname>sd_journal</structname> 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
-    <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>3</manvolnum></citerefentry> and similar,
-    or those that are used to retrieve global information like
-    <citerefentry><refentrytitle>sd_journal_stream_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+    <para>Functions that operate on <structname>sd_journal</structname> objects are thread agnostic — a given
+    <structname>sd_journal</structname> 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
+    <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+    similar, or those that are used to retrieve global information like
+    <citerefentry><refentrytitle>sd_journal_stream_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and
     <citerefentry><refentrytitle>sd_journal_get_catalog_for_message_id</refentrytitle><manvolnum>3</manvolnum></citerefentry>
     — are fully thread-safe and may be called from multiple threads in parallel.</para>
   </refsect1>
index 56acabb441b0def0466add571442e162acf29106..187f7ef77c83cf97a356b485738eba5314d0ed31 100644 (file)
   <refsect1>
     <title>Notes</title>
 
-    <para>Function <function>sd_journal_get_catalog()</function> 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.</para>
-
-    <para>Function <function>sd_journal_get_catalog_for_message_id()</function> is are thread-safe and may be called in
-    parallel from multiple threads.</para>
+    <para>Function <function>sd_journal_get_catalog()</function> 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.</para>
+
+    <para>Function <function>sd_journal_get_catalog_for_message_id()</function> is thread-safe and may be
+    called from multiple threads in parallel.</para>
 
     <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/>
   </refsect1>
index 8492ca398f9a810e06c97e12358082625fa0f01a..05e7514f433f87f243cf995697deb62ccd382aaf 100644 (file)
@@ -6,10 +6,9 @@
 <refsect1>
   <title/>
 
-  <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>