libusb: Fix high CPU usage in callback thread

[Copilot]

Fix high CPU usage in callback thread due to loop w/o real sleep/context switch.
A few other multithreading bugs fixed along the way.

• hotplug callback thread now always sleeps w/o a timeout and waits for either a hotplug event or an exit event; exit event now correctly emited;

• process_hotplug_event() modified hid_hotplug_context.devs (appending/freeing nodes) without holding hid_hotplug_context.mutex, while hid_hotplug_register_callback() traverses the same list under that mutex when HID_API_HOTPLUG_ENUMERATE is set. A concurrent disconnect could free a node mid-traversal → use-after-free.

Closes: #782

[Youw]

@copilot We used to handle all evens in a queue while holding the lock on a mutex, and now we lock it only when manipulating the queue, but not when handling the event. Is there a benefit in that approach?

[Copilot]

@copilot We used to handle all evens in a queue while holding the lock on a mutex, and now we lock it only when manipulating the queue, but not when handling the event. Is there a be...

Yes — releasing the lock during event processing avoids two problems:

1. Blocking the producer: hid_libusb_hotplug_callback (which runs on hotplug_thread) must acquire the same mutex to enqueue events. If we held the lock during the (potentially long) callback invocation, the producer would stall for that entire duration. Releasing it lets new events be enqueued concurrently while an older one is being dispatched.

2. Deadlock prevention: If user callback code calls back into HIDAPI (e.g., hid_hotplug_deregister_callback), that call will attempt to acquire callback_thread.mutex. Holding it during processing would deadlock.

The tradeoff is that hid_hotplug_context.devs (the known-device list maintained inside process_hotplug_event) is modified without the lock, but that is safe because only callback_thread reads or writes devs — events are still processed serially within the single consumer thread.

[Youw]

@copilot I also see that devs is accessed from hid_hotplug_register_callback, even though it is done before the thread is created, maybe move that initialisation inside of the thread (to match cleanup of that variable at the end of the thread).
And would be great to explicitly mark that variable that it should only be accessed from that thread.

[Copilot]

@copilot I also see that devs is accessed from hid_hotplug_register_callback, even though it is done before the thread is created, maybe move that initialisation inside of the th...

Done in 3f4721e. devs is now initialized at the start of callback_thread (paired with its cleanup at the end), and its struct comment marks it as "Only accessed from callback_thread." The HID_API_HOTPLUG_ENUMERATE case in hid_hotplug_register_callback now enumerates devices locally (freed after use) so it never touches the thread-owned devs.

[Youw]

@CalcProgrammer1 could you check this change in you environment regarding high CPU usage? it should give even better result.