I like this! And had something similar in mind for a while.
The implementation seems nice and lean.

Just one thing: The queue that events are posted to are part of the event bus, instead of the event_bus_entry.
That saves memory if the events should be triggered event_thread style in some handler thread.
It costs some flexibility, like, if a thread would like to have the event posted to a different (e.g., its own vs some system wide predefined one) queue.
I think I'd prefer to have the target queue as part of the entry struct, I think it allows some nifty patterns, allowing to access thread local state in a synchronized (serialized) manner, ...

Also the queue-ptr-in-bus behavior can be trivially implemented with the queue-ptr-in-entry variant (albeit at the extra cost of the ptr per entry vs ptr per bus).

What do you think?

And bike shedding - naming wise I'm not sure I'm happy with "event bus". What do you think about "event_source", or "event hooks", ...?

Did you consider using nested structs vs. pointers? events are already using them.

struct event_bus_entry_t {
  list_node *next;
  event_t event[];  // dynamic struct member
}

struct my_event_entry {
   event_bus_entry_t bus_entry;
   event_callback_t whatever_event; // all event types have an event_t as first member, so this is legal wrt. C's aliasing rules
}

my_event_entry foo;
event_bus_add(&bus, &foo.bus_entry); // it is a bit more clumsy to use

event_t* event_bus_entry_get_event(event_bus_entry_t *entry) { entry->event[0] }; // event is an array (of size 1)

Did you consider using nested structs vs. pointers? events are already using them.

Yes, that's why I use pointers here. This way we can use the bus with events that are already extended (e.g. event_callback_t in the test application)

Murdock results

✔️ PASSED

3b38b29 tests/event_source: add test for event sources

Artifacts

• Documentation preview

This only reflects a subset of all builds from https://ci-prod.riot-os.org. Please refer to https://ci.riot-os.org for a complete build for now.

And bike shedding - naming wise I'm not sure I'm happy with "event bus". What do you think about "event_source", or "event hooks", ...?

I agree here, to me this reads as an event fan out construct and less as a bus. I would go with something along the lines of "event_hook" or "event_subscription". What do you think?

Please squash btw :)

I'm struggling a bit to find consistent naming with non-bus alternatives.

How about:

event_bus_t -> event_source_t,
event_bus_entry_t -> event_subscriber_t,
event_bus_add/remove/post() -> event_source_attach/detach/trigger().

event_source_subscriber_t seems awefully long. I think we can get away with a name that doesn't match the prefix because we might have a use for event_subscriber_t elsewhere. :)

Sounds good to me.

event_source_subscriber_t

I prefer event_source_subscription_t. Personally I don't mind the slightly longer name.

I prefer event_source_subscription_t. Personally I don't mind the slightly longer name.

Would be fine with me, and consistent.

Like so?

I think this is good to go, please squash and maybe fix bus->"event sources" (or similar) in the commit messages.

Down the line:

1. we should provide static inline initializer functions. Easier to reason about, easier to auto-generate Rust bindings for.
2. we should discuss if clist wouldn't be a better choice, as it provides O(1) append on both ends. That would then keep the event execution order in event insertion order. Not if sure that's beneficial.

Squashed.

Still interested in this one?

I'm curious what we'll build with this!

bors merge

Build succeeded:

• Murdock
• static-tests
• tools-build-success