Description
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.