Date: Tue, 17 Oct 1995 12:16:11 EST From: "Kaleb S. KEITHLEY" <kaleb@x.org> To: Terry Lambert <terry@lambert.org> Cc: hackers@freefall.FreeBSD.org Subject: Re: getdtablesize() broken? Message-ID: <199510171616.MAA09068@exalt.x.org> In-Reply-To: Your message of Mon, 16 Oct 1995 19:10:53 EST. <199510170210.TAA26181@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > >Poll, anyone? > > > > >Poll is inferior to select, > > > > Debatable. > > Not. 8-). > > > >both because of the 10ms limit on timeout > > >resoloution > > > > Man pages only say that if the host does not support millisecond > > accuracy then the value is rounded up to the nearest legal value > > available. > > 10ms is the argument resoloution. Do you mean 1000 usec (1000usec == 1msec)? All the man pages I have say the timeout parameter specifies milliseconds (ms or msec). None say anything about 10ms granularity. Spec1170 is the first document I've seen that specs poll, for that matter it's also the first I've seen that documents select. The spec for both poll and select says: If the requested timeout interval requires a finer granularity than the implementation supports, the actual timeout interval will be rounded up to the next supported value. > On Solaris, it's 10ms, ... Perhaps Sun's implementation! There is no reason why a FreeBSD implmentation of poll could not have granularity of one ms/msec/millisecond, so long as there's nothing in FreeBSD itself that prevents it from achieving that granularity. Seems like if select can do 4usec then poll should have no difficulty achieving 1msec. > ... while select() > is till 4uS. select() wins. 8-). How can that be? I can specify all the way down to 1usec and the system will round up. On Solaris select(3) calls poll(2) (there is no select(2)) This suggests that select on Solaris will actually round all the way up to 1000usec (1msec) or that select can somehow trick poll into using finer granularity than it would otherwise! The fact that select(2) has a granularity as small as 4 usec (microseconds) would seem to have little or no bearing when you're doing actual polling. Both are specified as returning as soon as data is available on one (or more) of the file descriptors. > > That hasn't been my experience. poll(0, NULL, 10000); waits 10 seconds > > on SunOS, all SVR4-en I have here, HPUX, and AIX. In fact in SVR4 > > select(3) is implemented using poll(2). > > That's a bug in SVR4. SVR4 is broken and bogus in many, many ways. > > That's why this is "FreeBSD" instead of "FreeSVR4". 8-). Non sequitur! We're talking about whether poll can be used like select for fine grain delays. You assert that poll doesn't wait when nfds==0. I say that assertion is false based on empirical evidence. Man pages and Spec1170 offer nothing to suggest otherwise. > > In theory poll could be more efficient because there's less bit > > twiddling to do and unless you're polling thousands of files poll > > needs to transfer far less data to the kernel address space. Back > > in the days of 1.1.5.1 I started to look at what it would take to > > add poll. Maybe I'll look again. > > I agree that it could, though I'd want a timeval struct instead of an > integer time value That wouldn't be compliant with the definition of poll in Spec1170. That would be a Bad Thing. All you're really saying is you want to be able to specify a delay shorter than 1000usec (1msec) or longer than INT_MAX (or MAXINT) milliseconds or shorter than 1000 usec (1msec). 24 days isn't long enough for you? :-) As I said, if you're doing "real" polling, I don't believe minimum granularity is really an issue.If you're doing some sort of round-robin busy looping with non-blocking I/O you could probably call poll with a zero msec timeout; then the time overhead of the syscall would be the minimum delay. If that's still not adequate then you need a new function upoll(). :-) > implicitly limited to a 10ms resoloution by its units. As above, I believe you mean 1000 usec? -- Kaleb
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510171616.MAA09068>