Date: Mon, 27 May 1996 21:25:48 EST From: "Kaleb S. KEITHLEY" <kaleb@x.org> To: Terry Lambert <terry@lambert.org> Cc: hackers@freefall.FreeBSD.org Subject: Re: Forgiving select() call. Message-ID: <199605280125.VAA17242@exalt.x.org> In-Reply-To: Your message of Mon, 27 May 1996 14:24:28 EST. <199605272124.OAA09092@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Any thoughts on writing a poll() which allows a variable number of bits > > > passed in the fd_set (or new) structure to get around FD_SETSIZE limits > > > > Poll is (finally) specified in Spec1170 and it doesn't use bits in an > > fd_set. If you want a system call that does this, don't call it poll. > > And if you want a poll() system call that has beeter than 10ms timer > resoloution, don't call it poll(). The select() call *does* have > some advantages over poll(), still. Yup, well, seems like we've had this talk before. The spec for poll allows delays with 1ms resolution. You can argue all you want about how the SVR4 poll implementation is inherently flawed to yield the actual 10ms granularity you cite, and you're no doubt correct, but that doesn't mean that a FreeBSD implementation need be similarly flawed. And, FWIW, SVR4 select(3) is implemented using poll(2), so select on SVR4, in and of itself, isn't going to have any better granularity than poll. At the other end of the spectrum poll doesn't allow for arbitrarily long delays, i.e. longer than MAXINT ms. A new API is needed that takes, e.g. a struct timeval instead of an int to request large delays. -- Kaleb KEITHLEY
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605280125.VAA17242>