Messages in this thread | | | From | richard clark <> | Date | Wed, 15 Mar 2023 11:31:45 +0800 | Subject | Re: Question about select and poll system call |
| |
Adding more people...
I did some homework and found that the FD_SETSIZE question seems related with below 2 commits: 1. 4e6fd33b7560 ("enforce RLIMIT_NOFILE in poll()") "POSIX states that poll() shall fail with EINVAL if nfds > OPEN_MAX. In this context, POSIX is referring to sysconf(OPEN_MAX), which is the value of current->signal->rlim[RLIMIT_NOFILE].rlim_cur in the linux kernel...". IOW, the nfds suggested by POSIX is kind of configurable, making sense for Linux kernel to link it with rlimit. 2. bbea9f69668a ("fdtable: Make fdarray and fdsets equal in size") This commit uses the fdt->max_fds instead of FD_SETSIZE suggested by POSIX, but gives no reason to do that.
Curiously I did some tests on Linux and macOS, the testing code snippet:
static int test(void) { int err = 0; int nfds = FD_SETSIZE; fd_set rfds, wfds, efds;
FD_ZERO(&rfds); FD_ZERO(&wfds); FD_ZERO(&efds);
err = select(nfds + 1, &rfds, &wfds, &efds, NULL); if (err < 0) perror("select failed"); return err;
}
The test results as: Linux ~~~~ Blocked at select
macOS ~~~~~~ select failed: Invalid argument
Thanks!
On Tue, Mar 14, 2023 at 10:31 AM richard clark <richard.xnu.clark@gmail.com> wrote: > > Adding linux-arm-kernel@lists.infradead.org ... for more possible feedback:) > > On Tue, Mar 14, 2023 at 10:28 AM richard clark > <richard.xnu.clark@gmail.com> wrote: > > > > Hi, (Sorry, not find the maintainers for this subsystem, so to the lkml) > > > > There're two questions about these system calls: > > 1. According to https://pubs.opengroup.org/onlinepubs/7908799/xsh/select.html: > > ERRORS > > [EINVAL] > > The nfds argument is less than 0 or greater than FD_SETSIZE. > > But the current implementation in Linux like: > > if (nfds > FD_SETSIZE) > > nfds = FD_SETSIZE > > What's the rationale behind this? > > > > 2. Can we unify the two different system calls? For example, using > > poll(...) to implement the frontend select call(...), is there > > something I'm missing for current implementation? The Cons and Pros, > > etc > > > > Thanks,
| |