(untested) Signal overlapped from caller in LUsb0_ControlTransfer #33
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an attempt to deal with libusb 1.0.24 or later which always uses
asynchronous control transfers. libusb will pass an OVERLAPPED structure and
use this afterwards to check that the transfer has finished.
The transfer will still be forced synchronous here, but by
signalling the finished transfer the caller will not be reporting
timeouts for actual finished transfers.
Additional merge request comments:
I am not sure if this is correct, if it compiles, or if it solves any problem. There is however some timeouts showing up in libusb, for example in libusb/libusb#94 (comment) which I could possibly think is caused by this.
The libusbK.sys backend deals properly with both sync and async requests. The libusb0.sys backend would up to now ignore the overlapped for an async request. I think the rework in libusb 1.0.24 made everything async. The suggested change makes it "fake async". Probably it could be made to work again with libusb changes instead, but I think offering a "fake async" here is good anyway.
Alternatively the overlapped from the caller can be passed down to the DeviceIOControl instead of the extra overlapped currently created in _usb_io_sync(). I will suggest this in another merge request. It still doesn't make it true async. I think the repacking done in usb_control_msg() requires allocating a new buffer for setup + outgoing data, and it is not obvious for me how to free that buffer at the right point in time later, if going asynchronous.