From owner-freebsd-hackers  Sat Jun 16 18:53:49 2001
Delivered-To: freebsd-hackers@freebsd.org
Received: from sockratte.schell.de (polz.de [195.20.238.74])
	by hub.freebsd.org (Postfix) with SMTP id 8642F37B401
	for <freebsd-hackers@FreeBSD.ORG>; Sat, 16 Jun 2001 18:53:43 -0700 (PDT)
	(envelope-from sascha@schumann.cx)
Received: (qmail 9899 invoked from network); 17 Jun 2001 01:53:42 -0000
Received: from unknown (HELO rossini.schumann.cx) (217.225.216.12)
  by polz.de with SMTP; 17 Jun 2001 01:53:42 -0000
Received: from localhost (localhost [127.0.0.1])
	by rossini.schumann.cx (Postfix) with ESMTP
	id 9ED525E007; Sun, 17 Jun 2001 03:52:58 +0200 (MEST)
Date: Sun, 17 Jun 2001 03:52:58 +0200 (MEST)
From: Sascha Schumann <sascha@schumann.cx>
X-X-Sender:  <sas@rossini.schumann.cx>
To: Alfred Perlstein <bright@rush.net>
Cc: <freebsd-hackers@FreeBSD.ORG>
Subject: Re: poll(2)'s arbitrary limit
In-Reply-To: <20010616194155.L1832@superconductor.rush.net>
Message-ID: <Pine.LNX.4.33.0106170337160.3712-100000@rossini.schumann.cx>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-hackers.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-hackers>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-hackers>
X-Loop: FreeBSD.ORG

> 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