Date: Sat, 27 Feb 2016 14:02:41 -0500 From: Pedro Giffuni <pfg@FreeBSD.org> To: Jilles Tjoelker <jilles@stack.nl> Cc: Ronald Klop <ronald-lists@klop.ws>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r296109 - head/libexec/rlogind Message-ID: <56D1F2D1.4000008@FreeBSD.org> In-Reply-To: <20160227183841.GA62612@stack.nl> References: <201602262002.u1QK2298094838@repo.freebsd.org> <op.ydhtgxz8kndu52@53555a16.cm-6-6b.dynamic.ziggo.nl> <56D1B725.4000506@FreeBSD.org> <20160227183841.GA62612@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/27/16 13:38, Jilles Tjoelker wrote: > 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. > Of course it pretty much depends on what you want to do. Yes, for something like talk we are fine with poll(). I also find poll() more readable than the alternatives. Pedro.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56D1F2D1.4000008>