Peter Dons Tychsen

I made a quick patch for win32 to show this concept. This also has the side-benefit of actually making the entire library actually thread safe (for win32 for now). https://github.com/libusb/hidapi/commit/169c524840778f71f47e2198d445e6a274b9a8ae...

>>Instead, I'd rather add an explicit check into each hid_close implementation: if there is any active call on this device - fail >>fast/crash the process/etc., as it is a design...

>> right, so you're forcing a non-free overhead for all users that don't need it at all. I am not sure I understand the logic here. So using a few...

>>This is the solution: https://github.com/libusb/hidapi/issues/146 >>Contributions are welcome. Nope. Same problem again. How will you define when it is safe to call hid_interrupt_read()? You claim that the library is not...

>>but you end up in some weird cases, when you're successfully finished ther read after the close is completed which is >>technically possible on Linux but logically an insanity from...

>> Please-please-please read my comment and understand that there is still a race-condition! I have read you comments. Your argument is based on the fact that you cannot call other...

I would still like to know if the current patch (which I just updated) has other races than the one where you erroneously call operations after close. If we accept...

@YgorSouza I totally agree. We probably need to work a bit more on the synchronization mechanism to make sure all of @Youw's concerns are met. I am not sure we...

1) I have made some patches to support libusb0 in libwdi/zadig under ARM64: https://github.com/dontech/libwdi This adds support for loading libusb0.sys on ARM64. 2) It has the same problem. Only works...

> Last I dove into it, ARM64's driver signing requirements are the same as x64 _except_ that no attestation-signed drivers for it can exist since it shipped after new signatures...