Comment 6 for bug 1868486

As an optimization, the (os/default/) epicsMessageQueue code will, when one party (send or recv) finds that the other party is always waiting, copy directly to the waiter's buffer. This avoids copying messages twice, but comes at a price in terms of complexity. This optimization drives the need for each party to be tracked individually, and to have a separate epicsEvent.

Given that the usage I've seen is with small messages, I wonder whether this optimization is worthwhile. Eliminating it would allow the use of a fewer (probably two) epicsEvent, and avoid the need to track parties individually. (could be similar to what I've done with epicsThreadPool)

When fixing this issue, it would be worth thinking about a simplification.