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

More detailed specification of the behaviour of Unix.select #3942

Closed
vicuna opened this issue Dec 30, 2005 · 5 comments
Closed

More detailed specification of the behaviour of Unix.select #3942

vicuna opened this issue Dec 30, 2005 · 5 comments

Comments

@vicuna
Copy link

vicuna commented Dec 30, 2005

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.

@vicuna
Copy link
Author

vicuna commented Jan 5, 2006

Comment author: @damiendoligez

IMO, if you want to know whether I/O is possible on a particular descriptor, the proper
solution is to call select with only that descriptor.

@vicuna
Copy link
Author

vicuna commented Jan 18, 2006

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.

@github-actions
Copy link

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.

@github-actions github-actions bot added the Stale label May 18, 2020
@xavierleroy
Copy link
Contributor

I'd rather treat the lists returned by Unix.select as sets, i.e. not specify anything about the order.

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 Unix.select) also took time O(length), so the overall complexity is unchanged.

Nowadays, applications that need to poll on many file descriptors don't use select. An example of an OCaml library for efficient polling: https://mmzeeman.home.xs4all.nl/ocaml/event-doc/Libevent.html .

@mmottl
Copy link
Contributor

mmottl commented May 18, 2020

Agreed, select should be avoided for applications that require a lot of connections now that mature alternatives are available.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants