Given there is no technical reason why this can’t work, I hope eventually you will consider it.
At the very least, this page should probably be taken down if it’s not officially supported.
That conflicts with this in the docs:
FreeRTOS API functions must not be called from within a critical section.
And how the FromISR functions are being called from task code.
Thank you for the feedback! We will look into the documentation you mentioned.
I vote for completly removing the mentioned pages from the official documentation. They smell like hacked out sleaze. Imho, there should never be any indication Anywhere that …FromISR functions could or should be used outside of ISRs, because even if that happens to work somehow and coincidentally in the current implementation, it shuts the door for future changes in the inner workings. If need be, a second parallel set of API functions can be published that currently map to their …FromISR counterparts but may in the future be implemented differently.
I worked for Microsoft in the 90s in The NT/Win95 days, and I can tell you a lot of stories about the grey zone between official and hacked out information and what happens if you don’t keep that grey zone as small and crisp as possible.
I will point out that to officially “Undocument” the functionality should require a “Major Version” update with a clear backward incompatibility warning (even though the existing code works). And it would still need to be supported in the LTS versions until their support expires.
Adding a new set of API entries (that might just be macros at first) giving them an alternate name (maybe the Alt suffix instead of FromISR, to point out their “Alternate API” meaning) could be done before, with a notice that using the FromISR version may be removed at a future version (That Future version being a Major Version bump).
The functionality of this operation has some clear, if limited, uses, and its “lightweight” nature is well within the goal space of FreeRTOS, so I see a real desire to keep it in some form. Basically, this “Alternate API” version provides calls that will either succeed or fail, without attempting to block, and which put off any indicated task switching until a later point in the code.
I’m not sure if I’m misreading this, but going back to the question of calling a queue api function from a critical section - that should not be done unless the block time is zero. My comments about how the synchronous and asynchronous ports work only holds true for within the implementation of the api functions themselves, and breaks down if the api is called from a critical section. If a queue api function needs to block it must do from the correct location within the api function - if it can’t block until exiting the function, when an application level critical section exits, it cannot complete the queue operation when the task next runs.
A large part of the discussion has move to the FromISR part of the Queue API, which of course can’t block, so that can’t be an issue. The question is should the page that describes the FromISR part of the API as an alternate lightweight version usable in tasks if with a critical section should stay.