johnl@esegue.segue.boston.ma.us (John R. Levine) (10/25/90)
I am writing some X code in which I want to display items to the screen as
they arrive from a back end via a pipe. To do a reasonable job, I need to
read both X events and pipe data at the same time. Under Sys V, there is
a handy poll() call similar to the BSD select() call that lets you wait until
there is activity on any of a set of file descriptors.
The problem is that, according to the manual, poll() is only guaranteed to
work on Streams devices. A little experimentation shows that under ISC 2.2
polling a pipe works nicely, but it's not clear whether that is standard
behavior or an ISC improvement. (There is such a thing as a streams pipe,
but the standard pipe system call doesn't make one, it makes a nameless FIFO,
as usual.)
Does anyone with experience with other Sys V versions know whether polling
pipes is always supposed to work? Since I only need to do this under X, we
can assume that streams are in the kernel, since without them X won't work.
TIA,
--
John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@esegue.segue.boston.ma.us, {ima|spdcc|world}!esegue!johnl
Atlantic City gamblers lose $8200 per minute. -NY Timeseric@femto.mks.com (Eric Gisin) (10/26/90)
The ability to poll pipes and ttys is an extension by Interactive (ISC), and is documented in the manual. select (in libinet) just calls poll. I understand SCO UNIX added a separate select system call, which has the ability to check file descriptor that poll can't. I don't know what ESIX does, since they don't have socket emulation. I would think that anyone who ports the BSD rsh to SysV would have to provide poll or select on pipes, otherwise you could not use rsh in pipelines.
dougm@ico.isc.com (Doug McCallum) (10/26/90)
In article <1990Oct24.184556.853@esegue.segue.boston.ma.us> johnl@iecc.cambridge.ma.us (John R. Levine) writes: >I am writing some X code in which I want to display items to the screen as >they arrive from a back end via a pipe. To do a reasonable job, I need to >read both X events and pipe data at the same time. Under Sys V, there is >a handy poll() call similar to the BSD select() call that lets you wait until >there is activity on any of a set of file descriptors. Definitely something that was needed in SYSV. > >The problem is that, according to the manual, poll() is only guaranteed to >work on Streams devices. A little experimentation shows that under ISC 2.2 >polling a pipe works nicely, but it's not clear whether that is standard >behavior or an ISC improvement. (There is such a thing as a streams pipe, >but the standard pipe system call doesn't make one, it makes a nameless FIFO, >as usual.) I don't know anyone else that added it, I haven't looked, but it is definitely an ISC addition. It was asked for a LOT as was using poll on tty devices. It is nice but applications using it won't be portable. Under V.3, pipes are still done the old way and not with STREAMS. Under V.4, this all changes. In most cases, the STREAMS pipe mechanism can substitute for real pipes. Of course, it isn't guaranteed that STREAMS pipes will ship with all systems. > >Does anyone with experience with other Sys V versions know whether polling >pipes is always supposed to work? Since I only need to do this under X, we >can assume that streams are in the kernel, since without them X won't work. There are two mechanisms for doing STREAMS pipe types of things. The original STREAMS pipe was /dev/spx and was used by RFS. This is what ISC uses in X. Then there is the STREAMS pty mechanism (/dev/ptmx, /dev/pts???) which can also be used for STREAMS terminal type things. /dev/spx has less overhead and existed prior to V.3.1 where /dev/ptmx did not exist in the earlier releases. The pty stuff is a little clunkier to deal with but is more likely to be shipped. It is also what AT&T uses for local X clients. Doug McCallum Interactive Systems Corp dougm@ico.isc.com
gaf@uucs1.UUCP (gaf) (10/27/90)
John R. Levine writes: >A little experimentation shows that under ISC 2.2 >polling a pipe works nicely, but it's not clear whether that is standard >behavior or an ISC improvement. (There is such a thing as a streams pipe, >but the standard pipe system call doesn't make one, it makes a nameless FIFO, >as usual.) That's funny - I've been told by ISC in no uncertain terms that poll() doesn't work on a FIFO, since it isn't a streams device. This info came back from a bug report I gave them complaining that select() appeared not to be working properly on FIFOs. select() calls poll(), and as you say poll() only works on streams devices. It is not standard, and it is not an ISC improvement. Getting X events from a FIFO doesn't work for me very well. What happens is they sit there, all queued up, until some other X event happens (enter, leave, etc). It seems select() (aka poll()) doesn't reject events from FIFOs, but if data on a FIFO is the only event happening, select() won't return. When some other event happens, the FIFO data gets read then. It's a pity. -- Guy Finney It's that feeling of deja-vu UUCS inc. Phoenix, Az all over again. ncar!noao!asuvax!hrc!uucs1!gaf sun!sunburn!gtx!uucs1!gaf
dougm@ico.isc.com (Doug McCallum) (10/28/90)
In article <345@uucs1.UUCP> gaf@uucs1.UUCP () writes: ... >That's funny - I've been told by ISC in no uncertain terms that poll() >doesn't work on a FIFO, since it isn't a streams device. This info came >back from a bug report I gave them complaining that select() appeared not >to be working properly on FIFOs. select() calls poll(), and as you say >poll() only works on streams devices. Poll is supposed to work on pipes, ttys and potentially other devices. hat does not mean it worked under other releases. To be more accurate about this, poll is supposed to work on pipes and tty devices under 2.2 and definitely did in the 1.0.6 release. Poll works on tty devices but did not work on pipes (or FIFOs) under 2.0.1 or 2.0.2. > >It is not standard, and it is not an ISC improvement. Getting X events >from a FIFO doesn't work for me very well. What happens is they sit there, >all queued up, until some other X event happens (enter, leave, etc). >It seems select() (aka poll()) doesn't reject events from FIFOs, but if >data on a FIFO is the only event happening, select() won't return. When >some other event happens, the FIFO data gets read then. It's a pity. I just checked and you are correct in the behavior. Apparently when the poll support was added back in it was not done completely. The support for poll on anything other than STREAMS is non-standard and applications that make use of any extensions (on ISC or SCO or anything else) are not going to be portable.
wgb@balkan.TNT.COM (William G. Bunton) (10/30/90)
In article <1990Oct28.035350.26736@ico.isc.com> dougm@ico.ISC.COM (Doug McCallum) writes: >In article <345@uucs1.UUCP> gaf@uucs1.UUCP () writes: >... >>That's funny - I've been told by ISC in no uncertain terms that poll() >>doesn't work on a FIFO, since it isn't a streams device. This info came >>back from a bug report I gave them complaining that select() appeared not >>to be working properly on FIFOs. select() calls poll(), and as you say >>poll() only works on streams devices. > >Poll is supposed to work on pipes, ttys and potentially other devices. >hat does not mean it worked under other releases. To be more accurate >about this, poll is supposed to work on pipes and tty devices under 2.2 >and definitely did in the 1.0.6 release. Poll works on tty devices but >did not work on pipes (or FIFOs) under 2.0.1 or 2.0.2. And I've been told in no uncertain terms that it doesn't work on tty's. In fact, I've been told that because it's not supported on tty's, that is a valid reason for it to hang the entire vt/console subsystem. If you compile the short program included at the end of this post, and run it from a tty on 2.2, you will find no VT accepting input until you kill the program. >I just checked and you are correct in the behavior. Apparently when the poll >support was added back in it was not done completely. > >The support for poll on anything other than STREAMS is non-standard and >applications that make use of any extensions (on ISC or SCO or anything else) >are not going to be portable. I'd like to suggest it wasn't done completely for tty's either, and maybe someone ought to check up on it. Doug, I'm certainly not flaming you, I appreciate you and Dick posting. But I am a but pissed off over the response I got from support@isc for a bug report, and was waiting for a chance to respond. Thanks :-) Here's the program: -------------- cut here ------------------ #include <stdio.h> #include <stropts.h> #include <poll.h> main() { struct pollfd pfd; pfd.fd = 0; pfd.events = POLLIN; poll(&pfd, 1, -1); } ----------- cut here -------------- Bill -- William G. Bunton | An engineer is a man who can do for five bob wgb@balkan.tnt.com | what any bloody fool can do for a quid. Tools & Techniques, Austin, TX | -- origin unknown
wgb@balkan.TNT.COM (William G. Bunton) (10/30/90)
In article <1990Oct28.035350.26736@ico.isc.com> dougm@ico.ISC.COM (Doug McCallum) writes: >In article <345@uucs1.UUCP> gaf@uucs1.UUCP () writes: >... >>That's funny - I've been told by ISC in no uncertain terms that poll() >>doesn't work on a FIFO, since it isn't a streams device. This info came >>back from a bug report I gave them complaining that select() appeared not >>to be working properly on FIFOs. select() calls poll(), and as you say >>poll() only works on streams devices. I've been told the same, in the same terms, about tty devices. In fact, I reported that select (which, as we all know, calls poll), when run on a tty, will hang the entire console/vt subsystem until the program issueing the select (poll) terminates. The response was: "select is a Berkeley-ism, unsupported in this usage by Unix V3." I swear I read that ISC modified poll to work on pipes and ttys. But even if not, it would seem more reasonable for poll to return an error, or ignore that descriptor, rather than freezing the console. >about this, poll is supposed to work on pipes and tty devices under 2.2 >and definitely did in the 1.0.6 release. Poll works on tty devices but >did not work on pipes (or FIFOs) under 2.0.1 or 2.0.2. Yes, poll works on tty devices (as long as the driver is asy, not fas. If fas, the console/vt system seems to survive, it's the program issueing the poll that has problems), but at the expense of the console. This doesn't seem like an acceptable trade-off to me. >I just checked and you are correct in the behavior. Apparently when the poll >support was added back in it was not done completely. I'd like to suggest that when poll support was added back in for tty devices it was not done completely either. Note that it works fine when run on one of the ports on my ACE card, but not when run on a COM (i.e. tty0[01]). If anyone is interested, here's a nice short program that when run on a tty will freeze the console until the program is killed: --------- cut here --------------- #include <stdio.h> #include <stropts.h> #include <poll.h> main() { struct pollfd pfd; pfd.fd = 0; pfd.events = POLLIN; poll(&pfd, 1, -1); } ------------ cut here ----------- Bill -- William G. Bunton | An engineer is a man who can do for five bob wgb@balkan.tnt.com | what any bloody fool can do for a quid. Tools & Techniques, Austin, TX | -- origin unknown
dave@dptechno.UUCP (Dave Lee) (10/31/90)
In article <1990Oct24.184556.853@esegue.segue.boston.ma.us> johnl@iecc.cambridge.ma.us (John R. Levine) writes: >I am writing some X code in which I want to display items to the screen as >they arrive from a back end via a pipe. To do a reasonable job, I need to >read both X events and pipe data at the same time. Under Sys V, there is [ stuff deleted about poll on pipes ]. I had a similar problem, I wanted a xterm type window as a sub window of a larger X application, where the user could run a program in the window, but still do other X stuff like menus. The best solution I found was to implement this with pty's, and select. select() on ISC2.0.2 uses poll, but I wanted a "more portable" solution, and made the assumption that any X interface would also support select() on the file descriptor associated with the display. This has so far been correct for all systems our X apps run on -- Sun,HP-UX,ISC2.0.2,SparcStation. Then (of course) I got a little fancier, and wrote an X_Next() that would allow you to queue up a list of file descriptors that desired input/output and arrange a callback routine to be called when input/output was availible. Good place to place timer events also, since you are doing a select(), might as well put the time to the next timer as the timeout time... Note, that using pty's are more complicated than pipes, and more system dependant. Not only do the ioctl's vary, but the filenames of the master and slave devices vary, but oh well ... -- Dave Lee uunet!dptechno!dave
dougm@ico.isc.com (Doug McCallum) (10/31/90)
In article <1990Oct30.133825.19829@balkan.TNT.COM> wgb@balkan.TNT.COM (William G. Bunton) writes: ... >And I've been told in no uncertain terms that it doesn't work on >tty's. In fact, I've been told that because it's not supported on >tty's, that is a valid reason for it to hang the entire vt/console >subsystem. Who at ISC has told you it doesn't work? In any case, I compiled your program and ran it on several different systems; 2.0.2, 2.2 and one that is a little beyond 2.2. It has the correct behavior on all of them. The vt/console subsystem does not hang. The program exits as soon as a newline is entered as it should. The poll blocks until the newline if a tty is in canonical input mode. > >I'd like to suggest it wasn't done completely for tty's either, and >maybe someone ought to check up on it. All of my attempts to duplicate your problems fail. I have heard that poll doesn't work quite right on a COM port that is being used with modem signals but has a cable that isn't correctly wired. I haven't tried that; I'm not part of support, just someone that wants to help and don't really have the time to try strange wiring schemes. The modifications are in the generic tty code so should work the same way on the console, a COM port or other tty unless the standard tty code has been replaced in some way (like with a different line discipline). Because of poll being done in the generic code, poll should not be able to lock the vt/console subsystem. The poll code sits above it. The only time I would expect problems is if you are running a default configuration but trying to run more than 32 applications all using poll (or select) on a tty device at the same time or if you changed the value of NXTTY in /etc/conf/pack.d/kernel/space.c inappropriately. Doug McCallum Interactive Systems Corp. dougm@ico.isc.com
bruce@segue.segue.com (Bruce Adler) (11/01/90)
In the manual "386/ix TCP/IP Programmer's Supplement - Version 1.1.0"
(which is found within the book titled "386/ix TCP/IP Guide") it says at
the bottom of page 21:
"On the 386/ix Operating System, select essentially provides the
same functions as the poll system call but uses a different syntax.
select has the same restrictions as poll, but under 386/ix,
poll has been extended to support non-STREAMS file descriptors.
In particular, pipes, pty, and tty devices are supported."
I suspect the 1.2 version of the manual says the same thing, but I will
verify this later today.
If, as you say, poll() and select() don't work identically on all
releases of INTERACTIVE UNIX/386 3.2.x then it's clearly a bug. The
only questions in my mind are:
1. Does select have the same extensions as poll (probably but
the above paragraph is ambiguous)?
2. Does the console qualify as a tty type device?
3. Is the phrase "tty devices" intended to include all the
various brands of multi-port serial cards?
--
bruce@segue.com, ism.isc.com!segue!bruce, aero.org!segue!bruce