How to handle GetOverlappedResult blocking forever on read/write
TamToucan opened this issue · 12 comments
I have a problem on Windows7 where GetOverlappedResult blocks forever. I don't think the problem is HIDAPI, but I'm trying to understand how to use HIDAPI correctly to avoid this. For instance I was surprised that if I pull out the device during a write, but then call write again the WriteFile returns ERROR_IO_PENDING and so the GetOverlappedResult blocks.
Now obviously for the simple case I can not call the write after I get an error, but I believe there is a case where the device is removed just before the write and so I don't get an error and it simply blocks.
How exactly should I be handling this?
try the branch at:
https://github.com/signal11/hidapi/commits/windows_write_timeout
I tested it but I couldn't get the guy I made it for to confirm that it fixed his problem. If it works, I'll get the relevant patch (1 second timeout) into master.
Yes that works. Whenever I disconnect during read or write I've not seen block on further read/write attempts. Thanks!
FYI one thing I found when I was looking into this was http://support.microsoft.com/kb/156932 It says not to call GetOverlappedResult if the read/write returned TRUE. Don't know if actually matters.
I've found a couple of other things, but they are different issues so I'll raise new issues if that's ok. Thanks for the fix.
Does closing this issue mean that it works with the branch?
Sorry, yes, that's what my first sentence was trying to say. I've still got a problem somewhere which can cause the hid_read GetOverlappedResult to hang, but I'm sure it's not HIDAPI's problem.
try https://github.com/signal11/hidapi/tree/write_timeout_2 and see if that works for you. I now only call GetOverlappedResult() and WaitForSingleObject() if there WriteFile() returns false.
I can't test thoroughly right now, but it appears to work.
Yes that doesn't make any difference. I believe my problem is "lower down" and not an issue with HIDAPI. These are new devices and even without unplugging anything I sometimes get it that the ReadFile returns IO_PENDING, but the GetOverlappedResult then blocks forever. I've got one device that fairly consistently fails at the same place, but only when plugged in via HUB, but my 2 devices can both fail with a direct connection.
My guess is something wrong on the device side, but unfortunately I currently have no way to debug that, plus I'm new to all this so that doesn't help.
So in summary, the branch fixed my problem when unplugging devices whilst being used, but I'm left with what I'm pretty sure is something unrelated to HIDAPI.
I'll merge this into master before closing :)
Hello everyone,
Has any progress been made with this issue? I'm encountering the exact same problem.
It's been years since I looked at this however there are differences between what's on master at the final version I ended up using. I've attached that version, it's missing the changes on master for the max string length, but other than that all the changes are my additions. It looks like it doesn't block on GetOverlappedResult (so it can't hang), but I'm afarid it's been way too long to remember why these were made and what the implications are.
thanks a lot! I'll have a look.
I'm currently wondering if by any chance someone has made a wrapper around chromium hid source code: https://chromium.googlesource.com/chromium/src/+/master/device/hid/
Hi All,
I am having this same issue on WIn7 Pro SP1 only where hid_read_timeout is blocking on GetOverlappedResult(). I looked at Tam's changes and they look like the changes mentioned on the usage page on Microsoft's MSDN developer website. I have looked at the USB trace on my device and it is sending back the correct response, its just that the windows call ( getOverlappedResult() )never returns which makes my app hang forever. I have taken the changes provided by Tam and testing with them right now.
If it works then is there a plan to adopt these changes in hidapi?
Hi. It certainly was my experience that getOverlappedResult was never returning. Just to add that my app has been running with these changes with no problems for several years now and has hundreds of thousands of users.