You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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).
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.
The text was updated successfully, but these errors were encountered: