From owner-svn-src-head@freebsd.org Sat Feb 27 18:38:45 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1692FAB6C4F; Sat, 27 Feb 2016 18:38:45 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D988EA42; Sat, 27 Feb 2016 18:38:44 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from toad2.stack.nl (toad2.stack.nl [IPv6:2001:610:1108:5010::161]) by mx1.stack.nl (Postfix) with ESMTP id 18942B8061; Sat, 27 Feb 2016 19:38:41 +0100 (CET) Received: by toad2.stack.nl (Postfix, from userid 1677) id 414A7892F8; Sat, 27 Feb 2016 19:38:41 +0100 (CET) Date: Sat, 27 Feb 2016 19:38:41 +0100 From: Jilles Tjoelker To: Pedro Giffuni Cc: Ronald Klop , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r296109 - head/libexec/rlogind Message-ID: <20160227183841.GA62612@stack.nl> References: <201602262002.u1QK2298094838@repo.freebsd.org> <56D1B725.4000506@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56D1B725.4000506@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2016 18:38:45 -0000 On Sat, Feb 27, 2016 at 09:48:05AM -0500, Pedro Giffuni wrote: > In the case of rlogind, note that the above limitation [FD_SETSIZE] > has disappeared by using poll(2). > I will add that FreeBSD has a native poll(2) implementation, it is > not a wrapper around select as some old postings would suggest. > I don't have any plans to do a massive shakeup against select(2), this > was some lower hanging fruit that was easy to change. For new code > kqueue(2) should be preferred. The FD_SETSIZE can be a more important issue in library code which may be called from applications that have many descriptors open already. I don't agree with always using kqueue(2) for new code. Provided poll(2) has the necessary functionality and the number of file descriptors is low, using poll(2) tends to result in simpler code and better performance. Also, poll(2) is more portable and avoids a failure mode from the kqueues rlimit. -- Jilles Tjoelker