table of contents
- bookworm 252.31-1~deb12u1
- bookworm-backports 254.16-1~bpo12+1
- testing 257-2
- unstable 257.1-4
SD-EVENT(3) | sd-event | SD-EVENT(3) |
NAME¶
sd-event - A generic event loop implementation
SYNOPSIS¶
#include <systemd/sd-event.h>
pkg-config --cflags --libs libsystemd
DESCRIPTION¶
sd-event.h is part of libsystemd(3) and provides a generic event loop implementation, based on Linux epoll(7).
See 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) for more information about the functions available.
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. Dispatching events is strictly ordered and subject to configurable priorities. In each event loop iteration a single event source is dispatched. 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, as this contradicts these goals due the limitations of the underlying epoll(7) primitives.
The event loop implementation provides the following features:
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.
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.
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)
systemd 254 |