Why not allow queue receive without copy if destination size is zero

Kernel
1

I’m wondering why doesn’t the API allow a queue receive without copying the output.
I have two patterns where this capability would be ideal:

  1. A queue with one reciever where the receiver uses peek to operate on the element, but keep it allocated, while working with it. Then since work is done, just wants to take it out of the queue.
  2. A case where you just want to clear an element, like to make room for a priority one, but not reset the whole queue.

This is currently not allowed, but is there a good reason it needs to be how it is?

/* The buffer into which data is received can only be NULL if the data size
     * is zero (so no data is copied into the buffer). */
    configASSERT( !( ( ( pvBuffer ) == NULL ) && ( ( pxQueue )->uxItemSize != ( UBaseType_t ) 0U ) ) );
2

xQueuePeek ?
The 2nd case is not supported as far as I know.

3

Sure Peek lets you see it. But receive copies it second time. My questions is why does it have to waste that effort?

4

Got it. Probably because peeking a queue is a corner case and rarely used and the special case of a dummy receive adds code to the normal code path. So everybody would pay for the corner case. I’d prefer to add a dedicated API then like … xQueueDiscard ? Don’t know.

5

So you do not want to remove the element as soon as you read it but at a later point. Would you please elaborate your use case where you want to use this pattern.

6

With 1 receiver, peek gives you safe access to the element already, and it already copies it. Since it already copied, you should be able to remove it from the queue, thus freeing the space without copying it again.

7

Sure that would be fine also. The Receive API already checks for null destination, which it could also use as an indicator flag of not to copy. Currently it rejects this though.