libusb_handle_events_timeout() only handles one event

[egnor]

It's possible I misunderstand the desired behavior, but:

"If a zero timeval is passed, this function will handle any already-pending events and then immediately return in non-blocking style."

The question is whether it will handle _all_ work that needs to be done at that point. The quote above seems to indicate that it will. However, my observations and also my reading of the code seems to indicate that it basically does _one_ item of work (handles a single event).

This makes it somewhat difficult to use in a polling mode application. I call libusb_handle_events_timeout() periodically, hoping to handle everything necessary. However, it seems like it "falls behind" in some cases, only handling some events (one event?) each time it's called, and if events arrive at a faster rate than the function is called, then it doesn't work.

Furthermore, I can't tell if any events were handled; otherwise, I could just keep looping and calling it until no more events are handled. I can tell whether any of my own callbacks are invoked, but that's not the whole story. For example if I have submitted a transfer with libusb_submit_transfer(), then it appears as if this requires processing in libusb_handle_events_timeout(). (I'm not 100% sure.)

I can try to provide a repro case. One way is to call libusb_submit_transfer() a lot to set up a whole pile of pending transfers, then call libusb_handle_events_timeout() -- only some of them (one of them?) actually get queued.

So, either:

• I am on crack, libusb_handle_events_timeout() with a zero timeout definitely handles ALL pending events (unlike with a nonzero timeout, where it's documented to handle ONE pending event), and I should go soak my head and figure out the problem with my code;

• libusb_handle_events_timeout() with a zero timeout indeed only handles ONE pending event (or not all of them, anyway), in which case I think the documentation should be changed and a workaround identified for polling operation.

Thx for any help and/or head-soaking you can provide.

[stuge]

Replying to egnor:

So, either:

• I am on crack, libusb_handle_events_timeout() with a zero timeout definitely handles ALL pending events (unlike with a nonzero timeout, where it's documented to handle ONE pending event), and I should go soak my head and figure out the problem with my code;

• libusb_handle_events_timeout() with a zero timeout indeed only handles ONE pending event (or not all of them, anyway), in which case I think the documentation should be changed and a workaround identified for polling operation.

Could also be that the code should be fixed, if it doesn't handle all events. Please feel free to have a look into the libusb.git testing branch, and attach a documentation patch to this ticket according to what you find. Thanks!

[egnor]

Happy to do so!

I was sort of hoping someone could authoritatively tell me what the behavior is supposed to be. I'm not sure if this is a doc bug, a real bug, or a feature. :-) Once I know the intent, I can try to verify/modify as appropriate.

[xiaofan]

Cross-reference:
​https://github.com/libusbx/libusbx/issues/6

Pete thinks that this may have been fixed with the timeout handling issues.

[xiaofan]

Hans has since put forward a comprehensive analysis of the problem and proposed a patch for this issue. It has nothing to do with the timeout handling actually as per Hans.
Ref: ​https://github.com/libusbx/libusbx/issues/6 (refer to the post by Hans).

[hjelmn]

There is a fix in libusbx. Looks good to me so I am pulling this to my tree for inclusion in 1.0.16.