OpenSuSE Man Pages

Man Page or Keyword Search:
Man Architecture
Apropos Keyword Search (all sections) Output format
home | help
x SuSE Linux 13.1-RELEASE x
x SuSE Linux 13.1-RELEASEx
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:

        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_BOOTTIME 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 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).

        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
       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                                                        SD-EVENT(3)

Want to link to this manual page? Use this URL:
<
http://star2.abcm.com/cgi-bin/bsdi-man?query=sd-event&sektion=3&manpath=>

home | help