| Previous | Next |
| kIOUSBDeviceTransferredToCompanion | kIOUSBHighSpeedSplitError |
kIOUSBSyncRequestOnWLThread
A callback attempted to block the USB workloop
kIOUSBSyncRequestOnWLThread means a synchronous request was made from the IOUSBFamily workloop thread, commonly from a completion callback. The code is a threading and reentrancy contract, not evidence that the endpoint itself is malformed. A synchronous request waits for progress that can require the same workloop to run, so allowing it in that context can deadlock the client or block unrelated USB work.
The useful distinction is between where the failure was reported and where the request should run. A completion callback may decide what happens next, but it must not turn that decision into a blocking read, write, control request, or recovery action on the workloop.
Safe next step
- Log the callback type, endpoint, interface version, and call stack that led to the synchronous request.
- Replace follow-up work from the callback with the corresponding asynchronous operation and advance a per-device state machine from its completion.
- Keep operation ownership and cancellation rules explicit: a device removal, pipe stall, or timeout can complete an asynchronous request after the higher-level workflow has moved on.
- Perform blocking protocol work only from a context that does not own the IOUSBFamily callback path.
References
- Apple: kIOUSBSyncRequestOnWLThread
- Apple: IOUSBFamily error codes
- libusb: asynchronous I/O and event-callback restrictions
Looking for a different code? Search another status or error code.