#include <systemd/sd-event.h>
enum { SD_EVENT_INITIAL, SD_EVENT_PREPARING, SD_EVENT_ARMED, SD_EVENT_PENDING, SD_EVENT_RUNNING, SD_EVENT_EXITING, SD_EVENT_FINISHED, };
sd_event_prepare() checks for pending events and arms necessary timers. If any events are ready to be processed ("pending"), it returns a positive, non-zero value, and the caller should process these events with sd_event_dispatch().
sd_event_dispatch() dispatches the highest priority event source that has a pending event. On success, sd_event_dispatch() returns either zero, which indicates that no further event sources may be dispatched and exiting of the event loop was requested via sd_event_exit(3); or a positive non-zero value, which means that an event source was dispatched and the loop returned to its initial state, and the caller should initiate the next event loop iteration by invoking sd_event_prepare() again.
In case sd_event_prepare() returned zero, sd_event_wait() should be called to wait for further events or a timeout. If any events are ready to be processed, it returns a positive, non-zero value, and the events should be dispatched with sd_event_dispatch(). Otherwise, the event loop returned to its initial state and the next event loop iteration should be initiated by invoking sd_event_prepare() again.
sd_event_get_state() may be used to determine the state the event loop is currently in. It returns one of the states described below.
sd_event_get_iteration() may be used to determine the current iteration of the event loop. It returns an unsigned 64bit integer containing a counter that increases monotonically with each iteration of the event loop, starting with 0. The counter is increased at the time of the sd_event_prepare() invocation.
All five functions take, as the first argument, the event loop object event that has been created with sd_event_new(). The timeout for sd_event_wait() is specified in usec in microseconds. (uint64_t) -1 may be used to specify an infinite timeout.
The event loop knows the following states, that may be queried with sd_event_get_state().
SD_EVENT_INITIAL
SD_EVENT_PREPARING
SD_EVENT_ARMED
SD_EVENT_PENDING
SD_EVENT_RUNNING
SD_EVENT_EXITING
SD_EVENT_FINISHED
A simplified flow chart of the states and the calls to transition between them is shown below. Note that SD_EVENT_PREPARING, SD_EVENT_RUNNING and SD_EVENT_EXITING are not shown here.
INITIAL -<---<---<---<---<---<---<---<---<---<---<---<---\ | | | ^ | | v ret == 0 | sd_event_prepare() >--->--->--->--->- ARMED | | | ^ | ret > 0 | | | | | v v ret == 0 | PENDING <---<---<---<---<---< sd_event_wait() >--->--->--+ | ret > 0 ^ | | | | v | sd_event_dispatch() >--->--->--->--->--->--->--->--->--->--->/ | ret > 0 | ret == 0 | v FINISHED
On success, these functions return 0 or a positive integer. On failure, they return a negative errno-style error code. In case of sd_event_prepare() and sd_event_wait(), a positive, non-zero return code indicates that events are ready to be processed and zero indicates that no events are ready. In case of sd_event_dispatch(), a positive, non-zero return code indicates that the event loop returned to its initial state and zero indicates the event loop has exited. sd_event_get_state() returns a positive or zero state on success.
Returned errors may indicate the following problems:
-EINVAL
-EBUSY
-ESTALE
-ECHILD
Other errors are possible, too.
These APIs are implemented as a shared library, which can be compiled and linked to with the libsystemd pkg-config(1) file.
systemd(1), sd_event_new(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_run(3), sd_event_get_fd(3), sd_event_source_set_prepare(3)