Potential solution to MacOS hid_init/hid_exit issue

[k1-801]

One of the known thread-safety-related limitations on MacOS is that hid_init and hid_exit have to be called on the same thread. The only thing hid_exit really does there is destroy a HidManager. We could just leave that on the end user's shoulders, or we could resolve it internally. The problem might only arise if the user's application accidentally runs hid_init in a side thread before the main thread even gets a chance to call it (example: a static object constructor in C++ might do that).

We can't, of course, track the thread it was created in to ensure it closes in it - but, theoretically, this issue could be easily mitigated by giving the manager it's own thread to live in, which apparently would always be suspended by the sleeping RunLoop waiting for events, sacrificing zero processing power and only a small amount of ram. The manager would be created AND destroyed within the thread's function, guaranteed to be in the same thread. hid_init would have to start the thread and then wait at a barrier for the manager to be created. Then hid_exit would essentially be built the same way as hid_close, sending an event to stop the thread. That's about it.

[Youw]

All true.

I was thinking about having its own thread for init/deinit on macOS.
Just never had a chance to get it done.

[tresf]

We could just leave that on the end user's shoulders

Ran into this recently after some new threading was added to a downstream application. We decided to wrap calls documented here #45 (comment) into a single thread, which seems to have fixed the issue. Since we're actually downstream of downstream, we submitted the patch to the library we depend upon that wraps hidapi functionality. I'm not sure if the patch will be accepted, but I wanted to offer gratitude for documenting this.

[marciopamplona]

Hello, reverting this change seems to fix the issue. Any drawbacks on doing this ?

[Youw]

If will break other scenarios, not similar to yours.