macOS hid.c created a separate thread for runloop

[mcuee]

Ref: cvuchener/hidpp#17 (comment)

cvuchener (author of hidpp) seems to say this may not be a necessary and he thinks there is a potentially better way to use mach ports.

I do not understand this well. Just wondering why the macOS codes create a seperate thread for runloop.

[Youw]

HIDAPI needs a runloop to function. A runloop blocks the thread execution where it is invoked, and only processes "asyncronous" messages sent to objects that "live" in that runloop. Each macOS HID object has to live in a runloop as it is the only way to get HID interruptions (maybe some more, can't recall at the moment).

In theory - yes, HIDAPI could leave without a separate thread, but only if a calling code guarantees that in each thread where hid_init/hid_enumerate/hid_open (maybe not all of those, I'm not sure, but it doesn't really matter) is called - there is a runloop created and that it will be active for the whole hid_device lifetime.

This makes a limitation on the usage of the HIDAPI, and makes it really hard to use HIDAPI in simple UNIX-like console application, which knows nothing of the environment they run in (macOS)/runloops/etc.

[Youw]

What is done right now - a thread is created per-device.
In theory this can be optimised to create a thread per-context (we have only one context as per current implementation) for all devices.
But I think that is as much as hidapi could go to preserve the API and simple usage.

[noah-nuebling]

I’m currently working on the macOS port for HIDPP and my understanding is that, in the case of HIDPP all interaction with the device is blocking, and not asynchronous. That’s why it was unnecessary to create a separate thread to run the runLoop on.

As soon as you want any asynchronous interaction with the device like having a Device::registerCallback(callback) function that returns right away, you’d need a separate thread.

[Youw]

As soon as you want any asynchronous interaction with the device

and HIDAPI does that 1, 2

[mcuee]

Close this as it is answered.