Ubuntu Manpage: sd-event - A generic event loop implementation

Provided by: libsystemd-dev_252.5-2ubuntu3_amd64

NAME

       sd-event - A generic event loop implementation

SYNOPSIS

       #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_inotify(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_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:

        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.

NAME

SYNOPSIS

DESCRIPTION

NOTES

SEE ALSO