Date: Sun, 17 Jun 2001 03:52:58 +0200 (MEST) From: Sascha Schumann <sascha@schumann.cx> To: Alfred Perlstein <bright@rush.net> Cc: <freebsd-hackers@FreeBSD.ORG> Subject: Re: poll(2)'s arbitrary limit Message-ID: <Pine.LNX.4.33.0106170337160.3712-100000@rossini.schumann.cx> In-Reply-To: <20010616194155.L1832@superconductor.rush.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> Are you sure?
The code references the per-process limit
(p->p_rlimit[RLIMIT_NOFILE].rlim_cur).
> That would mean that the pollfd array is larger than the amount
> of open files you're allowed.
Right, the concatenation of multiple pollfd arrays does not
eliminate multiple occurences of fds in userland. So, we
might end up with n * p_rlimit[RLIMIT_NOFILE] entries where n
is any number >= 1. I have not evaluated yet the feasibility
of eliminating multiple occurences as that would involve
adding complexity for a special case to quite generic code.
> I think it may be a good idea to actually allow double
> RLIMIT_NOFILE and FD_SETSIZE for flexibility.
Yes. What do you think about adding a sysctl which defines
the maximum size (e.g. kern.maxpollfds)? That could be
initialized to kern.maxfilesperproc to maintain the current
behaviour.
- Sascha Experience IRCG
http://schumann.cx/ http://schumann.cx/ircg
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.33.0106170337160.3712-100000>