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
More detailed specification of the behaviour of Unix.select #3942
Comments
Comment author: @damiendoligez IMO, if you want to know whether I/O is possible on a particular descriptor, the proper |
Comment author: @mmottl The reason why this is not a good solution for us is, because we are implementing a messaging library that should have very low latency and very high throughput (> 100000 msgs/sec). System calls are extremely expensive and even just one superfluous call more quite noticably lowers throughput. Unfortunately, Linux still doesn't have a reasonable implementation of asynchronous I/O, which would be the optimum solution for this problem. |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
I'd rather treat the lists returned by Searching a FD in one of the returned lists takes time O(length) indeed, but constructing the list in the first place (in the stub code for Nowadays, applications that need to poll on many file descriptors don't use |
Agreed, |
Original bug ID: 3942
Reporter: @mmottl
Status: acknowledged (set by @damiendoligez on 2006-01-05T13:19:34Z)
Resolution: open
Priority: normal
Severity: feature
Version: 3.09.0
Category: standard library
Monitored by: @mmottl
Bug description
According to the C-implementation of "Unix.select", file descriptors in ready sets are returned in the reverse order in which they appeared in the argument lists. Could this please be explicitly specified as a guarantee in the documentation?
This way the user may be able to find out much more quickly (in O(1)) whether I/O is possible on a particular descriptor in a large set by simply making it the last one in the argument list and checking the first returned descriptor for equivalence.
The text was updated successfully, but these errors were encountered: