SD_BUS_ME...GET_COOKIE(3)

🌸 NAME 🌸

ok so bestie, these two functions β€” sd_bus_message_get_cookie and sd_bus_message_get_reply_cookie β€” literally just return the transaction cookie of a message. that's it. that's the whole vibe. πŸͺ


✨ SYNOPSIS ✨

#include <systemd/sd-bus.h>

int sd_bus_message_get_cookie(sd_bus_message *message,
                              uint64_t *cookie);

int sd_bus_message_get_reply_cookie(sd_bus_message *message,
                                    uint64_t *cookie);

πŸ’… DESCRIPTION πŸ’…

okay so picture this: sd_bus_message_get_cookie() hands you back the transaction cookie of a message. highkey iconic. and before you ask β€” the cookie uniquely identifies a message within each bus peer, but it is not globally unique (iykyk, don't @ me). it gets assigned when a message is sent. so no message, no cookie, periodt. 🫢

then we have sd_bus_message_get_reply_cookie() β€” this one returns the transaction cookie of the message that the specified message is a response to. like, when a reply message is generated for a method call message, its cookie is copied over into this field. the way that works?? honestly kind of genius. ⭐

⚠️ but bestie, listen: while every message that is transferred is identified by a cookie, only response messages carry a reply cookie field. so don't go looking for reply cookies where there aren't any. πŸ™ˆ

both functions take a message object as the first parameter, plus a place to store the 64-bit cookie in. easy. slay. πŸŽ€


πŸ”₯ RETURN VALUE πŸ”₯

on success, these calls return 0 or a positive integer. on failure, they return a negative errno-style error code. no in-between, no drama (well, the negative ones are drama). 😭

on success, the cookie / reply cookie is returned in the specified 64-bit unsigned integer variable. πŸ’–

πŸ’€ Errors

returned errors may indicate the following problems, and yes, they're giving main character energy:

  • -EINVAL β€” a specified parameter is invalid. lowkey your bad. πŸ™ˆ
  • -ENODATA β€” no cookie has been assigned to this message. this either means the message has not been sent yet (so obviously no cookie, she hasn't even left the house πŸ’…), or that the message is not a method response message and hence carries a reply cookie field. so double-check which one you're calling, bestie. 🫢

🌈 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. very convenient, very demure. ✨

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, and multiple independent objects may be used from different threads in parallel. so like… share the object, not the moment. πŸ¦‹

🚨 also, the code described here uses getenv(3), which is declared to be not multi-thread-safe. that means the code calling the functions described here must not call setenv(3) from a parallel thread. the recommendation is to only do calls to setenv() from an early phase of the program, when no other threads have been started. fr fr, do not test this. 🧚

πŸ‘‘ HISTORY πŸ‘‘

sd_bus_message_get_cookie() and sd_bus_message_get_reply_cookie() were added in version 209. vintage. iconic. she's been serving since 209. ⭐


πŸ¦‹ SEE ALSO πŸ¦‹


okay that's the whole page, you ate that πŸ’… this little number came to you straight from systemd 261.3, page SD_BUS_ME...GET_COOKIE(3) β€” go forth and read those cookies bestie, ily, mwah πŸŽ€βœ¨

πŸ“¦ where this page comes from