hidapi_thread_create() now returns int — heads-up for out-of-tree HIDAPI_THREAD_MODEL_INCLUDE thread models #829

New issue

Open

opened 2026-07-15 07:06:23 -05:00 by Youw · 0 comments

Youw commented

2026-07-15 07:06:23 -05:00

(Migrated from github.com)

The libusb backend hotplug work (#825) changed hidapi_thread_create() in libusb/hidapi_thread_pthread.h from returning void to returning int, so a pthread_create failure can be detected and unwound (a failed read-thread creation now reattaches the kernel driver and fails the open, rather than hanging forever in hidapi_thread_barrier_wait()).

Downstream projects that supply their own thread model via HIDAPI_THREAD_MODEL_INCLUDE (e.g. SDL) and still declare static void hidapi_thread_create(...) will fail to compile against the new call sites (if (hidapi_thread_create(...) != 0)). The migration is one line: change the return type to int and return the underlying create result (0 on success, non-zero on failure).

Filing so embedders get a heads-up before this reaches a release.

Drafted with Claude Code.

The libusb backend hotplug work (#825) changed `hidapi_thread_create()` in `libusb/hidapi_thread_pthread.h` from returning `void` to returning `int`, so a `pthread_create` failure can be detected and unwound (a failed read-thread creation now reattaches the kernel driver and fails the open, rather than hanging forever in `hidapi_thread_barrier_wait()`). Downstream projects that supply their own thread model via `HIDAPI_THREAD_MODEL_INCLUDE` (e.g. SDL) and still declare `static void hidapi_thread_create(...)` will fail to compile against the new call sites (`if (hidapi_thread_create(...) != 0)`). The migration is one line: change the return type to `int` and return the underlying create result (`0` on success, non-zero on failure). Filing so embedders get a heads-up before this reaches a release. _Drafted with Claude Code._