guy@gorodish.UUCP (09/18/87)
(Firing up the old crane and hauling this into comp.unix.wizards where it belongs....) > Poll is not better than select. At best, it is equivalent. It is definitely more complicated. On the good side: 1) It takes separate pointers to its input descriptor set and its output descriptor set. 2) It returns some special fake "events" for individual descriptors, so that you can, for example, find out which of the descriptors you tried polling were invalid, hung-up, etc.... On the bad side: 1) In order to do all this, you hand it a pointer to an array of structures, one element per descriptor; each element contains a descriptor, a set of events you're interested in (input available, output buffer space available, or high-priority message (this is pretty much equivalent to the "exceptional condition" of "select")), and a slot for the set of events that have acutally occurred. It is not clear whether you're better off having to reinitialize the FD masks for "select" or having to construct one of these arrays for "poll". It does take more effort for the kernel to read in and write out these arrays (and, if you're using more than NPOLLFILE == 30 descriptors, requires the kernel to *repeatedly* read them in and write them out). 2) The implementation of "poll" is more complicated. The 4BSD "select" implementation assumes that it is rare for more than one process to select on the same descriptor for the same purpose; in the implementations of "select" for the various object types I've seen, the first such process gets a pointer to its process table entry stored, but subsequent processes do not; a "collision" flag is set. If there is no collision, when an event occurs only the process waiting for that event occurs. If there is a collision, a broadcast wakeup is sent to all processes doing "select"s. The "poll" implementation registers interest in events by allocating an event cell and adding it to a list attached to the stream. This requires an allocator to manage that pool, and requires that these event cells be removed from that list when they are no longer applicable; the latter adds some complexity to "close" as well as to "poll". 4.[23]BSD has a variable "nselcoll" that is incremented whenever a broadcast wakeup is done. Unfortunately, as there was a power outage this morning, I can't check any machines that have been up for a long time; however, I have a crash dump from my machine taken recently, and after several hours of typing away (under SunView and inside EMACS, both of which do a fair number of "select"s) there were no collisions. NOTE: this may not be representative of any interesting workload. However, also note that you do not typically want to have two processes selecting for input from the same object; if they both wake up, they'll have to fight it out for who gets the next "read". Selecting for output is much less common, and even there you usually don't have two processes doing so on the same object. > If you want to poll on a non-stream, you are just plain out of luck. At > least all the doc I have seen said that poll only works for steams. This is true. As the standard System V terminal driver is not a streams driver, "poll" won't work on terminals. In fact, there is no streams tty driver supplied with the standard S5R3 or S5R3.1 source, unless it's buried somewhere very strange. (There is also no mechanism in the standard streams code to permit the VMIN/VTIME mechanism to be fully implemented in a streams tty driver.) > Select also can take a time-out time. As does "poll". > Barry also mentioned streams v. ptys. I believe that streams are superior > conceptually, but it they don't provide the functionality of a pseudo- > terminal then the conceptual niceness doesn't matter. One can implement ptys in the streams framework, but you need a streams-based tty driver module or modules. If you want to implement something such as the 4.[23]BSD pseudo-tty driver's "remote" or "packet" modes - which are *extremely* useful in some situations - you'd need a module to implement that as well. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
mash@mips.UUCP (John Mashey) (09/21/87)
In article <128@hotlg.ATT> nz@hotlg.UUCP (Neal Ziring) writes: ....mostly select/poll/V.3 stuff... >.... And as long as I am garnering flames here, >when is some version of System V going to have reasonably long filenames? The current version of our V.3 on MIPS boxen has a UCB filesystem underneath, including long names and symlinks. The (closely related) Silicon Graphics System V has a different filesytem, but has long names/symlinks. The V.3 release wasn't quite all the way there in cleaning up commands to not know about fixed-length directory names, but things were fixable. I'd assume there must be more such around, given the number of people who've moved UCB filesystems in there, especially in the technical market. (note: -> comp.unix.wizards, doesn't belong in comp.lang.c) -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086