Date: Tue, 08 Apr 1997 05:37:40 +0800 From: Peter Wemm <peter@spinner.DIALix.COM> To: Terry Lambert <terry@lambert.org> Cc: freebsd-current@freebsd.org Subject: Re: POLL & the Single FreeBSD'r Message-ID: <199704072137.FAA03511@spinner.DIALix.COM> In-Reply-To: Your message of "Mon, 07 Apr 1997 13:38:19 MST." <199704072038.NAA02051@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > > I implemented an openbsd-style implementation of poll() some time ago > > but it was mixed up in the middle of the upages stuff so it lot left. > > Since then, NetBSD have done a much better implementation, I'm very tempted > > to back out what I've done and start from scratch while looking at the > > NetBSD method. Basically, OpenBSD implemented poll() as an alternative > > interface to the select hooks in the kernel which means that poll() is > > limited to what select() can test for. NetBSD did it a lot better, by > > replacing the select hooks by poll hooks, and updating both front-ends to > > use the new poll backend. The main difference is that under NetBSD, you > > can poll for (say) ugent data on a socket as opposed to merely "readable". > > How does implementing select on top of poll hooks impact the ability > to specify a 1uS valued timeval struct for the select timeout? Does > it round to the 10ms granularity of poll, or does it work as expected > (and as documented in the select() man page)? It's got nothing to do with that. What I'm talking about is that the select functions in the device/file ops etc switch tables have a select backend that tests for FREAD, FWRITE or 0 (== exception). If you implement poll() over the top of that backend, you can't emulate the priority band stuff (urgent data). if, on the other hand, the backends are updated to scan for poll type events (read, write, urgent readable data, hangup, etc), you can implement poll() fully (and unambigiously), without hurting or penalising the select top end. Besides, all the timeout stuff is done in the top level code, select() or poll() in sys_generic. The fact that both call pollscan() or selscan() is irrelevant, because the scan routines are instant and do not sleep or timeout. The timeout is all up to the individual syscall handler. What you want is a high-resolution timer/sleep/schedule system, which we don't have, and nobody has offered to implement yet, so it's pretty unlikely that we'll see it in the near future. (This doesn't mean that it cannot be done, just that nobody has wanted it badly enough to do it. Messing with timers and a more precise sleep queue that can deal with the next event in microseconds for the timer programming might be enough, especially when combined with the RT schedule options) Incidently, the way the man page that you mention is written, it says the timeout is "the maximum amount of time to wait". It seems to me that rounding down to the nearest 10ms would make us more compliant with the man page, even though we can't control scheduling to guarantee an immediate wakeup. "waiting for the select event" != "waiting for process reschedule". So, if we ask for a 1us timeout, we'd be perfectly compliant with the man page to return immediately. In fact, we'd be compliant with the man page if we returned immediately no matter how long was asked for (0 seconds is not more than the maximum interval to wait for the selection to complete) - this goes to show that what is documented in the man pages isn't always good or useful. > Regards, > Terry Lambert > terry@lambert.org Cheers, -Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704072137.FAA03511>