With this scenario:
Step 3 will add a notification message to the queue set (it will now contain 1 element) using prvCopyDataToQueue(xPosition = queueSEND_TO_BACK)
Step 4 will add another notification message to the queue set, like for step 3, and the queue set will now contain 2 elements.
Step 5 will add another notification message to the queue set using prvCopyDataToQueue(xPosition = queueOVERWRITE). However, as far as I can see, this will actually prepend a message to the queue set, and then make sure the number of elements remains unchanged. The queue set will now contain 2 elements, but the element added in step 4 is lost!
As far as I can see, calling prvNotifyQueueSetContainer() from xQueueGenericSend() if xPosition is queueOVERWRITE is a mistake. It should probably only call prvNotifyQueueSetContainer if the overwrite operation actually adds an element (that is, the queue was empty before this call).
Thank you for the report. The queue functions are being refactored at
the moment, so I will leave this ticket open until after that is complete.
Is there any news about this bug?
If it is not fixed, I guess it deserves to be mentioned in the docs
Diff:
This is actually something that came up again in the forums very recently. Although in the forum I said I would just add an assert in the code to catch this occurance, I did actually attempt a fix (I say attempt as the code has not been tested so I don't know if it is a fix yet). In any case it will be in the next version once it is tested so I will close this ticket now.
Great, I am looking forward to the release
Seems to test out ok. Will be checked into SVN very soon.
Has the fixed been merged into a released version?