Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[libusb] Improve transfer results ordering #462

Closed
emaxx-google opened this issue Nov 25, 2021 · 1 comment
Closed

[libusb] Improve transfer results ordering #462

emaxx-google opened this issue Nov 25, 2021 · 1 comment
Labels
enhancement

Comments

@emaxx-google
Copy link
Collaborator

emaxx-google commented Nov 25, 2021 •
edited

Our current libusb implementation doesn't guarantee any particular ordering in case there are multiple transfers simultaneously in flight. This might or might not be a problem, depending on the needs of the consumer application.

There are several reasons that cause undetermined ordering:

  1. The transfer results from the JS API are temporarily put into a map that's ordered by some key (which is not a time nor a counter, but some other data).
  2. Pending transfers are stored in a set-inside-map, so they're not ordered either.
  3. [already fixed] Until recently, synchronous transfers had special implementation, such that synchronous transfers were fighting with asynchronous event loops (and who wins was determined, basically, on the order in which the POSIX conditional variable notified callers).
emaxx-google added a commit that referenced this issue Oct 27, 2023
@emaxx-google
[libusb] Handle transfers in FIFO
3217eaf 
When choosing which of active Libusb transfers should receive a
reply from the JS API, use the FIFO order rather than a random order.
Also change the internal structures so that FIFO is used uniformly,
which we'll use in follow-ups for correctly enqueueing JS API calls.

The FIFO order is more intuitive and better corresponds to Libusb
behavior on other platforms. Moreover, the FIFO property will be
crucial to avoid the situation when an enqueued JS API call is
discarded because the transfer happened to be resolved by the call
originally triggered by a different transfer.

This contributes to #462 and #1104.
@emaxx-google emaxx-google mentioned this issue Oct 27, 2023
Merged
emaxx-google added a commit that referenced this issue Nov 24, 2023
@emaxx-google
[libusb] Handle transfers in FIFO (#1105)
80a6d31 
When choosing which of active Libusb transfers should receive a
reply from the JS API, use the FIFO order rather than a random order.
Also change the internal structures so that FIFO is used uniformly,
which we'll use in follow-ups for correctly enqueueing JS API calls.

The FIFO order is more intuitive and better corresponds to Libusb
behavior on other platforms. Moreover, the FIFO property will be
crucial to avoid the situation when an enqueued JS API call is
discarded because the transfer happened to be resolved by the call
originally triggered by a different transfer.

This contributes to #462 and #1104.
@emaxx-google
Copy link
Collaborator Author

I believe #1105 and #1107 resolved this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@emaxx-google