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. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/4f17a6a6-0c12-49de-81ec-25b072b6d9efo%40googlegroups.com.
