Mark's tests fail for me as expected when added to the 3.15 branch on both MacOS and Linux, but not on RTEMS-pc386-qemu. RTEMS uses a different implementation of osdMessageQueue, as does VxWorks. Applying a reversed version of Ben's patch then results in some build warnings (status is never used) which I will clean up, but no test failures.
In comment #8 above Ben suggested:
> A similar fix may be needed in function mySend.
My guess is that the equivalent situation for sends would be that the queue is usually full, and the timeout to a send request that is waiting to be queues expires at about the same time that the receiver takes an item off and wakes up the sender. This is probably a much less common scenario, but until someone writes a test that proves that we have a bug there I don't particularly want to make the other change.
For now I will not do any more than is described above. Additional tests proving the other change is also required would be welcomed.
Mark's tests fail for me as expected when added to the 3.15 branch on both MacOS and Linux, but not on RTEMS-pc386-qemu. RTEMS uses a different implementation of osdMessageQueue, as does VxWorks. Applying a reversed version of Ben's patch then results in some build warnings (status is never used) which I will clean up, but no test failures.
In comment #8 above Ben suggested:
> A similar fix may be needed in function mySend.
My guess is that the equivalent situation for sends would be that the queue is usually full, and the timeout to a send request that is waiting to be queues expires at about the same time that the receiver takes an item off and wakes up the sender. This is probably a much less common scenario, but until someone writes a test that proves that we have a bug there I don't particularly want to make the other change.
For now I will not do any more than is described above. Additional tests proving the other change is also required would be welcomed.