table of contents
other versions
- jessie-backports 230-7~bpo8+2
- stretch 232-25+deb9u8
- testing 241-1
- stretch-backports 241-1~bpo9+1
- unstable 241-2
SD-EVENT(3) | sd-event | SD-EVENT(3) |
NAME¶
sd-event - A generic event loop implementationSYNOPSIS¶
#include <systemd/sd-event.h>
pkg-config --cflags --libs libsystemd
DESCRIPTION¶
sd-event.h 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_defer(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_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 honour 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: 1.I/O event sources, based on epoll(7)'s file
descriptor watching, including edge triggered events ( EPOLLET). See
sd_event_add_io(3).
2.Timer event sources, based on
timerfd_create(2), supporting the CLOCK_MONOTONIC,
CLOCK_REALTIME, CLOCK_BOOTIME clocks, as well as the
CLOCK_REALTIME_ALARM and CLOCK_BOOTTIME_ALARM clocks 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. See sd_event_add_time(3).
3.UNIX process signal events, based on
signalfd(2), including full support for real-time signals, and queued
parameters. See sd_event_add_signal(3).
4.Child process state change events, based on
waitid(2). See sd_event_add_child(3).
5.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).
6.Event sources may be assigned a 64bit priority value,
that controls the order in which event sources are dispatched if multiple are
pending simultaneously. See sd_event_source_set_priority(3).
7.The event loop may automatically send watchdog
notification messages to the service manager. See
sd_event_set_watchdog(3).
8.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¶
These APIs are implemented as a shared library, which can be compiled and linked to with the libsystemd pkg-config(1) file.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_defer(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_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 230 |