morgan/systemd
1
0
Fork 0
mirror of https://github.com/morgan9e/systemd synced 2026-04-15 00:47:10 +09:00
Code Issues Packages Projects Releases Wiki Activity
Files
main
systemd/man/threads-aware.xml

24 lines
1.2 KiB
XML
Raw Permalink Normal View History

man: be more explicit about thread safety of sd_journal Triggered by https://bugzilla.redhat.com/show_bug.cgi?id=1609349 This adds two generic paragaphs we include via xinclude. One is the "strict" version, which contains wording saying that we are thread agnostic and what that means. And the other is the "safe" version, for the cases we provide fully safety. Let's then change most man pages to use either of these generic paragraphs. With one exception: man/sd_journal_get_catalog.xml contains both kinds of function, we hence use manual wording.
2018-08-03 16:43:30 +02:00
<?xml version="1.0"?>
man: match doctype and root element
2023-12-23 09:57:43 +01:00
<!DOCTYPE refsect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
man: use same header for all files The "include" files had type "book" for some raeason. I don't think this is meaningful. Let's just use the same everywhere. $ perl -i -0pe 's^..DOCTYPE (book|refentry) PUBLIC "-//OASIS//DTD DocBook XML V4.[25]//EN"\s+"http^<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"\n "http^gms' man/*.xml
2019-03-14 14:40:58 +01:00
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
license: LGPL-2.1+ -> LGPL-2.1-or-later
2020-11-09 13:23:58 +09:00
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
man: be more explicit about thread safety of sd_journal Triggered by https://bugzilla.redhat.com/show_bug.cgi?id=1609349 This adds two generic paragaphs we include via xinclude. One is the "strict" version, which contains wording saying that we are thread agnostic and what that means. And the other is the "safe" version, for the cases we provide fully safety. Let's then change most man pages to use either of these generic paragraphs. With one exception: man/sd_journal_get_catalog.xml contains both kinds of function, we hence use manual wording.
2018-08-03 16:43:30 +02:00
<refsect1>
man: add required <title>
2023-12-23 10:05:38 +01:00
<title/>
man: be more explicit about thread safety of sd_journal Triggered by https://bugzilla.redhat.com/show_bug.cgi?id=1609349 This adds two generic paragaphs we include via xinclude. One is the "strict" version, which contains wording saying that we are thread agnostic and what that means. And the other is the "safe" version, for the cases we provide fully safety. Let's then change most man pages to use either of these generic paragraphs. With one exception: man/sd_journal_get_catalog.xml contains both kinds of function, we hence use manual wording.
2018-08-03 16:43:30 +02:00
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.)
2025-10-03 13:17:32 +02:00
<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>
man: be more explicit about thread safety of sd_journal Triggered by https://bugzilla.redhat.com/show_bug.cgi?id=1609349 This adds two generic paragaphs we include via xinclude. One is the "strict" version, which contains wording saying that we are thread agnostic and what that means. And the other is the "safe" version, for the cases we provide fully safety. Let's then change most man pages to use either of these generic paragraphs. With one exception: man/sd_journal_get_catalog.xml contains both kinds of function, we hence use manual wording.
2018-08-03 16:43:30 +02:00
man: adjust indentation
2023-12-24 10:46:55 +01:00
<para id="safe">All functions listed here are thread-safe and may be called in parallel from multiple threads.</para>
man: be more explicit about thread safety of sd_journal Triggered by https://bugzilla.redhat.com/show_bug.cgi?id=1609349 This adds two generic paragaphs we include via xinclude. One is the "strict" version, which contains wording saying that we are thread agnostic and what that means. And the other is the "safe" version, for the cases we provide fully safety. Let's then change most man pages to use either of these generic paragraphs. With one exception: man/sd_journal_get_catalog.xml contains both kinds of function, we hence use manual wording.
2018-08-03 16:43:30 +02:00
man: adjust indentation
2023-12-24 10:46:55 +01:00
<para id='getenv'>The code described here uses
<citerefentry project='man-pages'><refentrytitle>getenv</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
which is declared to be not multi-thread-safe. This means that the code calling the functions described
here must not call
<citerefentry project='man-pages'><refentrytitle>setenv</refentrytitle><manvolnum>3</manvolnum></citerefentry>
from a parallel thread. It is recommended to only do calls to <function>setenv()</function>
from an early phase of the program when no other threads have been started.</para>
man: add mention that libsystemd uses getenv() See #26688: getenv() is not thread-safe, and could a possible source of problems when a multi-threaded program calls setenv()/putenv()/unsetenv() in parallel. It is not possible to avoid getenv() calls in general, since $PATH, $LANG, $SHELL, $USER, $HOME, $TZ may need to be accessed at any time. Add a warning to our docs so that people are aware of the issue. Closes #26688. (Real fixes will need to be in glibc and gnome-shell or other programs.) The text is added to threads-aware.xml to be included in various places. By including it in libsystemd-pkgconfig.xml, it is automatically added to all sd-* pages. The text is also included explicitly in pages for a few other functions which are call getenv().
2023-03-07 20:25:58 +01:00
man: be more explicit about thread safety of sd_journal Triggered by https://bugzilla.redhat.com/show_bug.cgi?id=1609349 This adds two generic paragaphs we include via xinclude. One is the "strict" version, which contains wording saying that we are thread agnostic and what that means. And the other is the "safe" version, for the cases we provide fully safety. Let's then change most man pages to use either of these generic paragraphs. With one exception: man/sd_journal_get_catalog.xml contains both kinds of function, we hence use manual wording.
2018-08-03 16:43:30 +02:00
</refsect1>
Reference in New Issue Copy Permalink