Don't require UsbBus to be Sync #149
Conversation
|
Thank you for the PR. |
|
Sorry for the delay, I've had very little free time until recently. I looked into the request and this seems sound to me. I don't see an explicit reason why we are requiring the @mvirkkunen As the original author, do you see anything problematic with relaxing this bound? @dlaw Would you mind adding a CHANGELOG.md entry for this update as well? |
If the UsbBus is not Sync, it can still be used to make a UsbDevice, but that UsbDevice will not be Sync. This is quite limiting (as it mostly means that the USB device can't be accessed from interrupt contexts), but it is entirely safe from the Rust safety perspective.
|
I rebased on the latest upstream commit and added a changelog entry. Cheers! |
|
In light of not having a response here, I'm going to opt with accepting this and seeing if we discover any issues as we go along. |
Current behavior:
Proposed new behavior:
In other words, it is safe to allow a non-Sync UsbBus because Rust will NOT derive Sync for the UsbDevice in this case.
Why is this useful?
I have a hard-real-time firmware application which uses the USB interface to provide secondary (non-real-time) diagnostics. I poll the UsbDevice in my main loop, while all my other real-time stuff is handled in various interrupts. I do not use USB interrupts and I never access the UsbDevice from an interrupt context.
Unfortunately, making the UsbBus Sync requires the use of critical sections which damage the real-time interrupt timing. Eliminating the critical sections is totally safe in this situation, and solves my timing issues, but doing so means that the UsbBus cannot safely be marked as Sync.
impl Sync: dlaw/stm32-usbd-no-cs@7df1814#diff-b7dd6c6dc06c9c5da00a0c048df395e5fed282392d70a222b1d0e34706d9baf3R26