Sure. Right now, I just keep track of how many messages are in flight and I don't allow it to queue too many.
That's useful once you know what the bug is. Fortunately, I hit this bug before I had two threads (one receiving USB and one receiving ethernet) which would have made hunting it down quite painful. So, at least now I know that I *must* have a single thread acting as a gatekeeper on top of the rpmsg system.
If, however, you try to use a library on top of this bug that actually expects the O_NONBLOCK behavior to work, you will have a long debugging chain.
What *originally* tripped all of this was that I tried to use Rust and Tokio, which failed mysteriously. After far too much fruitless debugging, I switched down to Rust and mio, which also failed weirdly.
So, I switched down to C, poll, and O_NONBLOCK, which then gave the incorrect blocking behavior and the ERESTARTSYS. After *that*, I could actually pinpoint the incorrect behavior as belonging to pru_rpmsg and as being due to a full queue with incorrect blocking semantics.
Getting to that point, however, was neither pleasant nor straightforward.