gp@picuxa.UUCP (Greg Pasquariello X1190) (09/16/87)
According to an associate, there is a function in BSD called select(). This function is similar to sleep(), except that when awakened, the function can tell who or what woke it (i.e another computer, a port, etc.). Does anyone no if there is a similar function in System 5 V 3.1? If not, is there any way to create one? Thanks in advance. Greg "We thank you for your support.", Mr B.
bfb@mtund.UUCP (09/17/87)
--- 5.3 includes a better select() called poll(). Poll takes an array of pollfd's a long which is the number in the array and a timeout in milliseconds. You can also get a signal when there is something waiting to poll on. Undocumented features: timeouts >= than MAXINT/HZ crash the machine in strange ways in 5.3 may be fixed in 5.3.1. If you need to sleep with a granularity in milliseconds set the fd in a pollfd to -1 (ignore) then poll on it with the time you want to sleep in the timeout. More stuff than you wanted to know: 5.3 comes with a million new features that nobody inside att seems to know about. For those people that think sockects are the greatest thing since irradiated food read about TLI in section 3N. If you need pty's try a stream pipe and LD0 and ntty. For you att people still out there running 4.2, 5.3 is better and 9.5 is on the way. Barry Books mtune!mtund!bfb better is bigger
ekrell@hector.UUCP (Eduardo Krell) (09/17/87)
In article <307@picuxa.UUCP> gp@picuxa.UUCP (Greg Pasquariello X1190) writes: > According to an associate, there is a function in BSD called > select(). This function is similar to sleep(), except that > when awakened, the function can tell who or what woke it (i.e > another computer, a port, etc.). Does anyone no if there is > a similar function in System 5 V 3.1? If not, is there any > way to create one? Thanks in advance. System V Release 3 has a poll() system call which works like select(), but only for streams file descriptors. select() works on any file descriptor. Eduardo Krell AT&T Bell Laboratories, Murray Hill {ihnp4,seismo,ucbvax}!ulysses!ekrell
nz@hotlg.UUCP (09/18/87)
In article <891@mtund.ATT.COM> bfb@mtund.UUCP (jrc-Barry Books) writes: > --- > > 5.3 includes a better select() called poll(). Poll takes an array of > pollfd's a long which is the number in the array and a timeout in milliseconds. > You can also get a signal when there is something waiting to poll on. Poll is not better than select. At best, it is equivalent. 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. Select also can take a time-out time. 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. > More stuff than you wanted to know: > 5.3 comes with a million new features that nobody inside att seems to know about. Too true, unfortunately. Maybe AT&T-IS should publish a list of the order numbers for some of the neat books about SysVr3, so that those of us out here with no easy access to them can order our own copies easily. Barry, if you have a minute, please post some references about streams, TLI, and other neat features of 5.3. > For those people that think sockects are the greatest thing since irradiated > food read about TLI in section 3N. If you need pty's try a stream pipe and > LD0 and ntty. The problem with TLI, as I see it, is that there is no simple way to find out who you want to talk to on another machine. For instance, one piece of documentation I read (a long time ago) contained a line of code that went something like this: tli.address = get_tliaddr(); /* magic address-generator */ Sockets, as implemented on BSD, have a complicated but usable addressing scheme associated with them, courtesy of TCP, Internet, etc. Maybe this issue has been addressed since that last time I looked into it, but I have heard rumors to the contrary. > For you att people still out there running 4.2, 5.3 is better and 9.5 is on > the way. I hope that most of the people in AT&T who run Berk UNIX are up to 4.3 by now. SysVr3 is a big step in the right direction, but I'm afraid I feel that it still has some catching up to do. Pet Peeve: Why is Wollongong still making the Ethernet support product for the 3B2 and VAX for System V? Why doesn't AT&T have a competing product?? And as long as I am garnering flames here, when is some version of System V going to have reasonably long filenames? > Barry Books -- ...nz (Neal Ziring @ ATT-BL Holmdel, x2354, 3H-437) "You can fit an infinite number of wires into this junction box, but we usually don't go that far in practice." London Electric Co. Worker, 1880s
chris@mimsy.UUCP (Chris Torek) (09/18/87)
In article <891@mtund.ATT.COM> bfb@mtund.ATT.COM (Barry Books) writes: >[System] 5.3 includes a better select() called poll(). Poll takes >an array of pollfd's a long which is the number in the array and a >timeout in milliseconds. You can also get a signal when there is >something waiting to poll on. Select takes three pointers to `fd_set's, an int which specifies how many descriptors are described by the `fd_set's, and a timeout in microseconds. You can also get a signal (SIGIO) when a descriptor is ready. So what makes poll better? For the original poster: int select(int nfd, fd_set *r, fd_set *w, fd_set *ex, struct timeval *timeout) or (4.2BSD) int select(int nfd, int *r, int *w, int *ex, struct timeval *timeout) returns the number of descriptors that are ready for r(eading), w(riting), or that have ex(ceptions), returning within the time limit given by timeout, or waiting until at least one is ready if timeout==NULL. select always returns immediately if at least one descriptor is ready. *r, *w, and *ex are modified before select returns to reflect which descriptors in fact were readable or writable or had exceptional conditions pending. [Okay, Exceptional Conditions amount to out of band data on sockets.] -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
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
gwyn@brl-smoke.ARPA (Doug Gwyn ) (09/21/87)
In article <307@picuxa.UUCP> gp@picuxa.UUCP (Greg Pasquariello X1190) writes: > According to an associate, there is a function in BSD called > select(). This function is similar to sleep(), except that > when awakened, the function can tell who or what woke it (i.e > another computer, a port, etc.). Does anyone no if there is > a similar function in System 5 V 3.1? If not, is there any > way to create one? Thanks in advance. (This question should have been posted to comp.unix.questions.) select() tests for activity on a specified set of read/write/exception file descriptors, with an optional timeout to abort the select() if no activity happens. The UNIX System V Release 3.0 (or later) equivalent is poll(), which is found in the Programmer's Reference Manual under POLL(2). Note that it works only with STREAMS files, and that not all devices that could be are STREAMS devices. In particular, the terminal handler is not (yet) a STREAMS device. To test for activity on a terminal, System V programs typically use MIN,TIME (described under TERMIO(7), usually in the Administrator's Reference Manual) or O_NDELAY mode (see READ(2) and WRITE(2)).
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