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.

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

Windows: Max 256 concurrent transfers supported on Windows #92

Closed
mcuee opened this issue Aug 17, 2015 · 3 comments
Closed

Windows: Max 256 concurrent transfers supported on Windows #92

mcuee opened this issue Aug 17, 2015 · 3 comments

Comments

@mcuee
Copy link
Member

mcuee commented Aug 17, 2015

Ref:
http://libusb.org/ticket/157
http://comments.gmane.org/gmane.comp.lib.libusbx.devel/1881

A fixed size array of per-transfer data structures internal to the Windows backend limits the number of concurrent transfers.

@mcuee mcuee added the enhancement New features label Aug 17, 2015
@mcuee mcuee added this to the V2.0 release (API/ABI change) milestone Aug 17, 2015
@hiyuh
Copy link
Contributor

hiyuh commented Nov 20, 2015

maybe due to compiler optimization applied,
i may have max 128 fds limit as variant of this issue on cygwin.
also using int to index poll_fd[] looks simply uncool.

@dickens
Copy link
Member

dickens commented Dec 2, 2015

The maximum number of 256 transfers will be lifted when the event
abstraction code is merged in, but there will still remain a limit of 64
(MAXIMUM_WAIT_OBJECTS) per context. (Actually, there will be 62 transfers
available, since 2 HANDLEs will be reserved for the context event and
timer). The limit can be lifted altogether if the Windows backend uses the
RegisterWaitForSingleObject() API, but there is a measurable performance
penalty in doing so.

On Thu, Nov 19, 2015 at 6:26 PM, KIMURA Masaru notifications@github.com
wrote:

maybe due to compiler optimization applied,
i may have max 128 fds limit as variant of this issue on cygwin.
also using int to index poll_fd[] looks simply uncool.


Reply to this email directly or view it on GitHub
#92 (comment).

@hjelmn hjelmn added the windows label Mar 5, 2016
@dickens
Copy link
Member

dickens commented Jan 14, 2020

Closing as this was addressed in #592.

@dickens dickens closed this as completed Jan 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants