SD_EVENT...RATELIMIT(3)

📦
version 261.3 · 16 versions
, in ubuntu stonking

🌸 SD_EVENT...RATELIMIT(3) — the sd_event_source_set_ratelimit fam 💅

okay bestie, gather round, because this is the sd_event_source_set_ratelimit(3) manual page and it's genuinely such a vibe once you get it. it's all about telling your event sources "girl, chill, you're doing too much" ✨

✨ NAME ✨

sd_event_source_set_ratelimit, sd_event_source_get_ratelimit, sd_event_source_is_ratelimited, sd_event_source_set_ratelimit_expire_callback, sd_event_source_leave_ratelimit — literally just configuring rate limiting on event sources. that's the whole assignment 🎀

🦋 SYNOPSIS 🦋

#include <systemd/sd-event.h>

int sd_event_source_set_ratelimit(sd_event_source *source,
                                  uint64_t interval_usec,
                                  unsigned burst);

int sd_event_source_get_ratelimit(sd_event_source *source,
                                  uint64_t* ret_interval_usec,
                                  unsigned* ret_burst);

int sd_event_source_is_ratelimited(sd_event_source *source);

int sd_event_source_set_ratelimit_expire_callback(sd_event_source *source,
                                                  sd_event_handler_t callback);

int sd_event_source_leave_ratelimit(sd_event_source *source);

💖 DESCRIPTION 💖

the main character: sd_event_source_set_ratelimit()

so sd_event_source_set_ratelimit() is how you enforce rate limiting on an event source. when you use it, the event source gets temporarily turned off if it fires more often than a specified burst number within a specified time interval. and why do we care?? because it's a super simple mechanism to avoid event source starvation when your high priority event sources are firing very frequently 😭 like bestie, take a breather.

you pass the event source you're operating on as the first argument, a time interval in microseconds as the second argument, and a maximum dispatch limit (the "burst") as the third parameter.

so whenever the event source is dispatched more often than the specified burst within the specified interval, it gets placed in a mode similar to being disabled with sd_event_source_set_enabled(3) and the SD_EVENT_OFF parameter. BUT — and this is the important part — it's only disabled temporarily. once the specified interval is over, regular operation resumes. and then it gets disabled temporarily again the next time it hits the specified rate limiting. iconic behavior honestly 🔁

if either the interval or the burst value are specified as zero, rate limiting is turned off. no cap.

by default, event sources do not have rate limiting enabled. also super important: rate limiting and disabling via sd_event_source_set_enabled() are independent of each other, and an event source will only effect event loop wake-ups and is dispatched while it both is enabled and rate limiting is not in effect. both conditions, bestie. both 💅

sd_event_source_get_ratelimit()

this one's the gossip girl of the group — it may be used to query the current rate limiting parameters set on the event source object source. the previously set interval and burst values come back to you in the second and third argument 🫶

sd_event_source_is_ratelimited()

the vibe check 🔍. sd_event_source_is_ratelimited() may be used to query whether the event source is currently affected by rate limiting — i.e. it recently hit the rate limit and is currently temporarily disabled because of that.

sd_event_source_set_ratelimit_expire_callback()

set a callback function that gets invoked every time the event source leaves rate limited state 🎉 note that the function is called in the same event loop iteration in which the state transition occurred. no waiting around.

sd_event_source_leave_ratelimit()

the "you're free now" function 🕊️ — it may be used to immediately reenable an event source that was temporarily disabled due to rate limiting. this will reset the ratelimit counters for the current time interval.

the fine print

rate limiting is currently implemented for I/O, timer, signal, defer and inotify event sources. that's the list, periodt 💀

⭐ RETURN VALUE ⭐

on success, sd_event_source_set_ratelimit(), sd_event_source_set_ratelimit_expire_callback and sd_event_source_get_ratelimit() return a non-negative integer. on failure, they return a negative errno-style error code.

sd_event_source_is_ratelimited() returns zero if rate limiting is currently not in effect and greater than zero if it is in effect; it returns a negative errno-style error code on failure.

sd_event_source_leave_ratelimit() returns zero if rate limiting was not in effect on the specified event source, and positive if it was and rate limiting is now turned off again; it returns a negative errno-style error code on failure.

🙈 Errors 🙈

returned errors may indicate the following problems, bestie:

  • -EINVAL — source is not a valid pointer to an sd_event_source object.
Added in version 248.
  • -ECHILD — the event loop has been created in a different process, library or module instance.
Added in version 248.
  • -EDOM — it was attempted to use the rate limiting feature on an event source type that does not support rate limiting. rude of you, honestly 😭
Added in version 248.
  • -ENOEXEC — sd_event_source_get_ratelimit() was called on an event source that does not have rate limiting configured.
Added in version 248.

🌈 NOTES 🌈

the functions described here are available as a shared library, which can be compiled against and linked to with the libsystemd pkg-config(1) file 🧚

all functions listed here are thread-agnostic and only a single thread may operate on a given object at any given time. different threads may access the same object at different times. multiple independent objects may be used from different threads in parallel ✨

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 🌸

lowkey important: mixing setenv() in from another thread while this is running is giving chaos and undefined vibes. do it early or don't do it 💅

👑 HISTORY 👑

  • sd_event_source_set_ratelimit(), sd_event_source_get_ratelimit(), and sd_event_source_is_ratelimited() were added in version 248.
  • sd_event_source_set_ratelimit_expire_callback() was added in version 250.
  • sd_event_source_leave_ratelimit() was added in version 254.

🍓 SEE ALSO 🍓

sd-event(3), sd_event_add_io(3), sd_event_add_time(3), sd_event_add_signal(3), sd_event_add_inotify(3), sd_event_add_defer(3), sd_event_source_set_enabled(3)

and that's the whole page, bestie — go forth and rate limit responsibly 🫶 this was systemd 261.3, the SD_EVENT...RATELIMIT(3) manual page, signing off. slay 💜✨

📦 where this page comes from