From owner-freebsd-hackers Sun Jun 17 5:24: 5 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 E3C1837B403 for ; Sun, 17 Jun 2001 05:23:59 -0700 (PDT) (envelope-from sascha@schumann.cx) Received: (qmail 10039 invoked from network); 17 Jun 2001 12:23:58 -0000 Received: from unknown (HELO rossini.schumann.cx) (217.81.225.94) by polz.de with SMTP; 17 Jun 2001 12:23:58 -0000 Received: from localhost (localhost [127.0.0.1]) by rossini.schumann.cx (Postfix) with ESMTP id 3D1055E007; Sun, 17 Jun 2001 14:23:20 +0200 (MEST) Date: Sun, 17 Jun 2001 14:23:20 +0200 (MEST) From: Sascha Schumann X-X-Sender: To: Valentin Nechayev Cc: Subject: Re: poll(2)'s arbitrary limit In-Reply-To: <20010617123008.A585@iv.nn.kiev.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > sys/kern/sys_generic.c Right. > If there are no equal file descriptors in different pollfd arrays, > current maxfiles limit should not be reached. You can set the fd member of a pollfd to a negative value, marking the entry as unused. This allows you to easily exceed the per-process limit which is currently in place. Referring to IEEE 1003.1:200x: If the value of fd is less than 0, events shall be ignored, and revents shall be set to 0 in that entry on return from poll( ). > If some descriptors are equal, SGI's code is broken IMHO: when > two different pollfd structures has identical fd, result may be > indetermined. Nope, poll has to check each fd. Quoting from the same source: The fds argument specifies the file descriptors to be examined and the events of interest for each file descriptor. ^^^^ FreeBSD can still claim conformance, because the implementation can place restrictions on the maximum number of fds. I am advocating though that this restriction can be configured separately, because it has little relationship to kern.maxprocfiles. > I suppose this SGI state threads library can be simply recompiled > to use select() instead of poll(), this can be simple workaround. Well, historically, select(2) is the call with limitations while poll(2) is not. I agree though that in the current situation select is the preferred solution as I can simply define FD_SETSIZE for my application. > Also you can contribute code working with kevent(2), this will be > more efficient ;) I've actually implemented that already with no significant speed advantage; as various papers[1] have concluded, when select and poll are used properly they are not as inefficient as many people seem to assume. [1] http://www.citi.umich.edu/techreports/reports/citi-tr-00-4.pdf - 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