SD-EVENT(3)
π sd-event(3) β the whole vibe, explained
okay bestie, buckle up, because this one is literally the main character of the sd-event family β it's the manual page sd-event(3), and it's basically the group chat invite that tells you where all the other sd_event_* pages live π«Ά
β¨ NAME β¨
sd-event β a generic event loop implementation. that's it, that's the tweet. a whole event loop, ready to go π
πΈ SYNOPSIS πΈ
#include <systemd/sd-event.h>
pkg-config --cflags --libs libsystemd
π¦ DESCRIPTION π¦
sd-event.h is part of libsystemd(3), and it hands you a generic event loop implementation based on Linux epoll(7). yes, that epoll(7). iconic behavior honestly.
the functions it ships with each have their own page, so go read those for the full tea:
sd_event_new(3)sd_event_run(3)sd_event_add_io(3)sd_event_add_time(3)sd_event_add_signal(3)sd_event_add_child(3)sd_event_add_inotify(3)sd_event_add_defer(3)sd_event_add_memory_pressure(3)sd_event_source_unref(3)sd_event_source_set_priority(3)sd_event_source_set_enabled(3)sd_event_source_set_userdata(3)sd_event_source_get_event(3)sd_event_source_get_pending(3)sd_event_source_set_description(3)sd_event_source_set_prepare(3)sd_event_source_set_ratelimit(3)sd_event_wait(3)sd_event_get_fd(3)sd_event_set_watchdog(3)sd_event_exit(3)sd_event_now(3)
now, the design. and listen, this part is important, so likeβ¦ pay attention bestie π
the event loop design is targeted on running a separate instance of the event loop in each thread. it has no concept of distributing events from a single event loop instance onto multiple worker threads. none. zero. nope. so don't come at it with your thread-pool dreams π
dispatching events is strictly ordered and subject to configurable priorities. in each event loop iteration, a single event source is dispatched. and each time an event source is dispatched, the kernel is polled for new events before the next event source is dispatched. the event loop is designed to honor priorities and provide fairness within each priority. it is not designed to provide optimal throughput, because that would quite literally contradict these goals due to the limitations of the underlying epoll(7) primitives. so like, don't ask it to be fast, ask it to be fair π
π the features, bestie (a numbered slay list) π
- I/O event sources, based on
epoll(7)'s file descriptor watching, including edge triggered events (EPOLLET). seesd_event_add_io(3). - Timer event sources, based on
timerfd_create(2), supporting theCLOCK_MONOTONIC,CLOCK_REALTIME,CLOCK_BOOTTIMEclocks, as well as theCLOCK_REALTIME_ALARMandCLOCK_BOOTTIME_ALARMclocks that can resume the system from suspend. when creating timer events a required accuracy parameter may be specified which allows coalescing of timer events to minimize power consumption. seesd_event_add_time(3). - UNIX process signal events, based on
signalfd(2), including full support for real-time signals, and queued parameters. seesd_event_add_signal(3). - Child process state change events, based on
waitid(2). seesd_event_add_child(3). - Static event sources, of three types: defer, post and exit, for invoking calls in each event loop, after other event sources or at event loop termination. see
sd_event_add_defer(3). - Event sources may be assigned a 64-bit priority value, that controls the order in which event sources are dispatched if multiple are pending simultaneously. see
sd_event_source_set_priority(3). - The event loop may automatically send watchdog notification messages to the service manager. see
sd_event_set_watchdog(3). - The event loop may be integrated into foreign event loops, such as the GLib one. see
sd_event_get_fd(3)for an example.
π 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. slay.
β οΈ okay this next bit is the "read before you wreck something" part. the code described here usesgetenv(3), which is declared to be not multi-thread-safe. this means the code calling the functions described here must not callsetenv(3)from a parallel thread. it is recommended to only do calls tosetenv()from an early phase of the program when no other threads have been started. so like, do it first, before the threads wake up, and you're golden π
β SEE ALSO β
systemd(1), sd_event_new(3), sd_event_run(3), sd_event_add_io(3), sd_event_add_time(3), sd_event_add_signal(3), sd_event_add_child(3), sd_event_add_inotify(3), sd_event_add_defer(3), sd_event_add_memory_pressure(3), sd_event_source_unref(3), sd_event_source_set_priority(3), sd_event_source_set_enabled(3), sd_event_source_set_userdata(3), sd_event_source_get_event(3), sd_event_source_get_pending(3), sd_event_source_set_description(3), sd_event_source_set_prepare(3), sd_event_source_set_ratelimit(3), sd_event_wait(3), sd_event_get_fd(3), sd_event_set_watchdog(3), sd_event_exit(3), sd_event_now(3), epoll(7), timerfd_create(2), signalfd(2), waitid(2)
and that's the whole page, bestie π§ this lil beauty is from systemd 261.3 β mwah, go poll a kernel for me ππβ¨
π¦ where this page comes from
- ubuntu stonking: libsystemd-dev 261.3-0ubuntu3 Β· LGPL-2.1-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms