SD_EVENT_..._PRIORITY(3)

📦
version 261.3 · 17 versions
, in ubuntu stonking

💖 NAME 💖

okay so welcome to SD_EVENT_..._PRIORITY(3), aka the manual page for sd_event_source_set_priority, sd_event_source_get_priority, and the constants SD_EVENT_PRIORITY_IMPORTANT, SD_EVENT_PRIORITY_NORMAL, and SD_EVENT_PRIORITY_IDLE. Their whole thing? Set or retrieve the priority of event sources. That's the assignment, bestie. 💅

✨ SYNOPSIS ✨

Literally this:

#include <systemd/sd-event.h>

enum {
        SD_EVENT_PRIORITY_IMPORTANT = -100,
        SD_EVENT_PRIORITY_NORMAL = 0,
        SD_EVENT_PRIORITY_IDLE = 100,
};

int sd_event_source_set_priority(sd_event_source *source,
                                 int64_t priority);

int sd_event_source_get_priority(sd_event_source *source,
                                 int64_t *priority);

🦋 DESCRIPTION 🦋

sd_event_source_set_priority() is the one you call when you want to set the priority for the event source object you passed as source. The priority is an arbitrary signed 64-bit integer — yes, the whole range is available for ordering event sources.

When an event source is allocated with a call such as sd_event_add_io(3) or sd_event_add_time(3), its priority is initialized to SD_EVENT_PRIORITY_NORMAL (0), and you can change it with this call.

If multiple event sources have seen events at the same time, they are dispatched in the order indicated by the event sources' priorities. Event sources with smaller priority values are dispatched first. As well-known points of reference, these constants exist:

  • SD_EVENT_PRIORITY_IMPORTANT — -100, for event sources that shall be dispatched early
  • SD_EVENT_PRIORITY_NORMAL — 0, for event sources that shall be dispatched normally
  • SD_EVENT_PRIORITY_IDLE — 100, for event sources that shall be dispatched late

It is recommended to specify priorities based on these definitions, and relative to them — but the full 64-bit signed integer range is available for ordering event sources.

Priorities define the order in which event sources that have seen events are dispatched. Care should be taken to ensure that high-priority event sources (those with negative priority values assigned) do not cause starvation of low-priority event sources (those with positive priority values assigned). That's the dramatic part, but it's real.

The order in which event sources with the same priority are dispatched is undefined, but the event loop generally tries to dispatch them in the order it learnt about events on them. As the backing kernel primitives do not provide accurate information about the order in which events occurred, this is not necessarily reliable. However, it is guaranteed that if events are seen on multiple same-priority event sources at the same time, each one is not dispatched again until all others have been dispatched once. This behavior guarantees that within each priority particular event sources do not starve or dominate the event loop.

The priority of event sources may be changed at any time of their lifetime, with the exception of inotify event sources (i.e. those created with sd_event_add_inotify(3)) whose priority may only be changed in the time between their initial creation and the first subsequent event loop iteration. That inotify exception is important — don't sleep on it.

sd_event_source_get_priority() is the query side: use it to get the current priority assigned to the event source object source. 🫶

💀 RETURN VALUE 💀

On success, sd_event_source_set_priority() and sd_event_source_get_priority() return a non-negative integer. On failure, they return a negative errno-style error code.

😭 Errors 😭

Returned errors may indicate the following problems:

  • -EINVAL — source is not a valid pointer to an sd_event_source object.
  • -ENOMEM — Not enough memory.
  • -ESTALE — The event loop is already terminated.
  • -ECHILD — The event loop has been created in a different process, library or module instance.

👑 NOTES 👑

Functions described here are available as a shared library, which can be compiled against and linked to with the libsystemd pkg-config(1) file.

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.

The code described here uses getenv(3), which is declared to be not multi-thread-safe. This means that the code calling the functions described here must not call setenv(3) from a parallel thread. It is recommended to only do calls to setenv() from an early phase of the program when no other threads have been started. 🧚

🌈 HISTORY 🌈

sd_event_source_set_priority() and sd_event_source_get_priority() were added in version 229.

🎀 SEE ALSO 🎀

okay that's the page, bestie! source/version: systemd 261.3; date: the footer doesn't give us one, so I'm not inventing it — that's the whole footer vibe. SD_EVENT_..._PRIORITY(3) out. 🫶✨💅

📦 where this page comes from