EventQueue should permit static allocation

[kjbracey]

Description

EventQueue and Event always require an allocation to perform a call or call_in, meaning it can fail.

This is potentially fatal for state machines - there is no plan B if the queue fails.

There should be an alternative form that allows the storage for the struct equeue_event to be static, so the call cannot fail.

An analogous mechanism is provided in Nanostack's eventOS_event.h: eventOS_event_send_user_allocated.

I had previously thought that the equeue allocation mechanism and the dispatch mechanism were inherently coupled, meaning this would require an involved rework, but I now think that isn't the case. All the dispatching is just based on a linked list, no?

Looking at the API, it seems to me that we have a ready-made answer. Event could store the struct equeue_event as a member, rather than a pointer to one it allocates from the queue. It appears the existing API would fully support that - the equeue_event has the same lifetime as the Event, and its size is can be calculated at compile time from the templating.

It almost seems as if Event was made for this purpose...

Issue request type

[ ] Question
[X] Enhancement
[ ] Bug

[kjbracey]

Staring a bit harder, I see that Event is intended to function as a shared pointer onto the equeue_event, but that functionality is quite separate.

Seems like it could be split so that effectively Event is a SharedPtr<EventObject> with the necessary operator()/post/call.

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-352

[bulislaw]

@kjbracey-arm could you file it as a PREQ? I think it's very important our scheduler/event-loop doesn't rely on dynamic memory. It's just yet another thing that can go wrong.

[ciarmcom]

Thank you for raising this issue. Please note we have updated our policies and
now only defects should be raised directly in GitHub. Going forward questions and
enhancements will be considered in our forums, https://forums.mbed.com/ . If this
issue is still relevant please re-raise it there.
This GitHub issue will now be closed.

[kjbracey]

For the record, this feature was implemented by #11342