add the call to the CancelIo function #755

New issue

Open

opened 2025-06-24 07:44:56 -05:00 by jianweihao · 6 comments

jianweihao commented

2025-06-24 07:44:56 -05:00

(Migrated from github.com)

github.com/libusb/hidapi@f18d2c0768/windows/hid.c (L1129C3-L1133C4)

This piece of if-judgment code needs to add the call to the CancelIo function. Otherwise, after WaitForSingleObject times out and returns, WriteFile may fail with a certain probability and keep being stuck in the IO_PENDING state. It is necessary to add the CancelIo operation to continue sending data normally.

eg :

	if (res != WAIT_OBJECT_0) {
		/* There was a Timeout. */
		CancelIo(dev->device_handle);   // add function
		register_winapi_error(dev, L"hid_write/WaitForSingleObject");
		goto end_of_function;
	}

https://github.com/libusb/hidapi/blob/f18d2c0768bed300d13758dd9f52b57163c0498f/windows/hid.c#L1129C3-L1133C4 This piece of if-judgment code needs to add the call to the CancelIo function. Otherwise, after WaitForSingleObject times out and returns, WriteFile may fail with a certain probability and keep being stuck in the IO_PENDING state. It is necessary to add the CancelIo operation to continue sending data normally. eg : if (res != WAIT_OBJECT_0) { /* There was a Timeout. */ CancelIo(dev->device_handle); // add function register_winapi_error(dev, L"hid_write/WaitForSingleObject"); goto end_of_function; }

Youw commented

2025-06-24 08:50:24 -05:00

(Migrated from github.com)

@jianweihao how did you end up checking that piece of code? Did you happen to reproduce the issue?

And there is a problem adding CancelIo before register_winapi_error...

@jianweihao how did you end up checking that piece of code? Did you happen to reproduce the issue? And there is a problem adding `CancelIo` before `register_winapi_error`...

jianweihao commented

2025-06-24 08:54:57 -05:00

(Migrated from github.com)

Yes, we have the logic for switching USB HID devices, which triggers USB plug-in and removal during use. This is when the issue occurs. After calling the CancelIo function, the problem is resolved.

mcuee commented

2025-06-24 08:58:48 -05:00

(Migrated from github.com)

Yes, we have the logic for switching USB HID devices, which triggers USB plug-in and removal during use. This is when the issue occurs. After calling the CancelIo function, the problem is resolved.

Can you try this hotplug branch? Thank. The current main branch does not really support hotplug.
https://github.com/libusb/hidapi/tree/connection-callback

> Yes, we have the logic for switching USB HID devices, which triggers USB plug-in and removal during use. This is when the issue occurs. After calling the CancelIo function, the problem is resolved. Can you try this hotplug branch? Thank. The current main branch does not really support hotplug. https://github.com/libusb/hidapi/tree/connection-callback

jianweihao commented

2025-06-24 09:07:27 -05:00

(Migrated from github.com)

Yes, we have the logic for switching USB HID devices, which triggers USB plug-in and removal during use. This is when the issue occurs. After calling the CancelIo function, the problem is resolved.

Can you try this hotplug branch? Thank. The current main branch does not really support hotplug. https://github.com/libusb/hidapi/tree/connection-callback

This branch did not modify the code of hid_write. How does it handle the plug-in and removal logic? I'm very sorry because the modification was made 11 months ago. I can't find the equipment to reproduce the problem now, so I can't assist in verifying whether this branch can solve the problem.

> > Yes, we have the logic for switching USB HID devices, which triggers USB plug-in and removal during use. This is when the issue occurs. After calling the CancelIo function, the problem is resolved. > > Can you try this hotplug branch? Thank. The current main branch does not really support hotplug. https://github.com/libusb/hidapi/tree/connection-callback This branch did not modify the code of hid_write. How does it handle the plug-in and removal logic? I'm very sorry because the modification was made 11 months ago. I can't find the equipment to reproduce the problem now, so I can't assist in verifying whether this branch can solve the problem.

👍 1

Youw commented

2025-06-24 09:12:53 -05:00

(Migrated from github.com)

I'm pretty sure you'd hit the same issue with hid_write in that branch. I believe @mcuee wants to point out that since you're handling the hot plug/unplug scenarios for your devices, you should have some means to detect the removal/insertion of the device, so instead of making up something of your own, you might as well try that branch.

I'm pretty sure you'd hit the same issue with `hid_write` in that branch. I believe @mcuee wants to point out that since you're handling the hot plug/unplug scenarios for your devices, you should have some means to detect the removal/insertion of the device, so instead of making up something of your own, you might as well try that branch.

👍 1

jianweihao commented

2025-06-24 21:14:02 -05:00

(Migrated from github.com)

I'm pretty sure you'd hit the same issue with hid_write in that branch. I believe @mcuee wants to point out that since you're handling the hot plug/unplug scenarios for your devices, you should have some means to detect the removal/insertion of the device, so instead of making up something of your own, you might as well try that branch.

Thank you for your reply. I will do my best to locate the problematic device for testing. However, this process may take a considerable amount of time. Could you please evaluate the rationality of this change from a code perspective? I would be extremely grateful.

> I'm pretty sure you'd hit the same issue with `hid_write` in that branch. I believe [@mcuee](https://github.com/mcuee) wants to point out that since you're handling the hot plug/unplug scenarios for your devices, you should have some means to detect the removal/insertion of the device, so instead of making up something of your own, you might as well try that branch. Thank you for your reply. I will do my best to locate the problematic device for testing. However, this process may take a considerable amount of time. Could you please evaluate the rationality of this change from a code perspective? I would be extremely grateful.