Ihor Dutchak
Ihor Dutchak
let me make a readme section as a summary of this one, and then we can close it
That's what I meant - I've updated [connection-callback](https://github.com/libusb/hidapi/tree/connection-callback) to be in sync with master. As for [DJm00n:device_notify](https://github.com/DJm00n/hidapi/tree/device_notify) - yes it is not yet updated.
> Not really sure on how to maintain authorship Try pushing your changes directly to https://github.com/DJm00n/hidapi/tree/device_notify or open a PR against it. I'm sure @DJm00n will accept it as soon...
@DJm00n could you explicitly merge `libusb:connection-callback` branch into your `libusb:connection-callback` (with a merge commit)? otherwise the diff on Github is not what is should be
> just like when calling close() on a file `close` on a file is _not thread-safe_ and never has been. Only because of how the inode/descriptors work on Linux, it...
> It will not be visible in any real-life application as locking is some of the most efficient O/S operations. Please-please-please read my [comment](https://github.com/libusb/hidapi/pull/651#discussion_r1409218821) and understand that there is still...
> You claim that the library is not meant to be thread safe `hid_interrupt_read` would be the first thread-safe funciton in this matter, designed to be called concurently with `hid_read`....
> application that chooses to call close() in the middle of any file operation. But this is the applications responsibility to handle this and not the underlying library or O/S....
> You cannot in any way guarantee that this will work across multiple O/S without using synchronization. That is the implementation details. HIDAPI already uses syncronisation for _some cases_ where...