xMessageBufferReceive() ambiguous return value?

daniel29 wrote on Sunday, March 04, 2018:

Good morning all,

I’m new to FreeRTOS and currently pondering about the return value of xMessageBufferReceive().

A return value of 0 is returned if

  • either a timeout occured on an empty message buffer or
  • the length of the message exceeds the size of the copy buffer passed as parameter

The receiving end could remedy the second case by providing a bigger copy buffer - if it were aware of this situation but the current message buffer API does not offer the required information.

While the sender can use xMessageBufferSpacesAvailable() to check if a message-to-be-sent would fit into the message buffer, the receiver has no corresponding API function to check the size of a pending message.

I wonder why this.

Is it because sender and receiver need to have a separate means to convey buffer overflow situations anyway? For example, if the sender has a message to send that does not fit into the message buffer (because the receiver does not read from the message buffer fast enough or the message exceeds the total size of message buffer), I assume the sender has to notify the receveir anyway.


rtel wrote on Sunday, March 04, 2018:

I will add in a function that queries the size of the next message -
that way if 0 is returned without a timeout, indicating that the receive
buffer was too small to receive the message, the receiver could see how
large the buffer would need to be.

rtel wrote on Sunday, March 04, 2018:

I’ve created a function xMessageBufferNextLengthBytes(), which was
pretty simple as it predominantly uses other functions that already
exist, and its new tests are passing. It will get checked in shortly.

daniel29 wrote on Monday, March 18, 2019:

I’ve created a function xMessageBufferNextLengthBytes(),

Thanks for implementing this.

Could it make sense to have the same function also with an optional timeout?
I was thinking about an implementation to receive a message by allocating only as much memory as necessary instead of just allocating the maximum expected size.

Yes, I think so, I will add it to our backlog.