dowding@PRC.Unisys.COM (John Dowding) (11/02/89)
I am working on a program using multiple processes and pipes. Using Young's book (X Window Systems Programming and Applications with Xt), I built a prototype using XtAddInput (based on his example in section 5.8, pgs. 141-151). By putting a print statement at the top of the input callback, I found that it is being called continually, not just when new input appears on the pipe. Since this amounts to constantly polling the pipe for data, this is very inefficient. Does anyone know why this is happening or how to fix it? Thanks, John Dowding dowding@prc.unisys.com
swick@ATHENA.MIT.EDU (Ralph R. Swick) (11/02/89)
> By putting a print statement at the top of the > input callback, I found that it is being called continually, not just > when new input appears on the pipe. Have you installed public fix #8?
argv%turnpike@Sun.COM (Dan Heller) (11/03/89)
In article <8911021243.AA13857@LYRE.MIT.EDU> swick@ATHENA.MIT.EDU (Ralph R. Swick) writes: > > By putting a print statement at the top of the > > input callback, I found that it is being called continually, not just > > when new input appears on the pipe. > > Have you installed public fix #8? I've seen the exact same problem in R4-Alpha. The problem is that the select() call in WaitForSomething (or whatever it's called) determines that a file descriptor is "ready" for reading, but there is no associated ioctl(fd, FIONREAD, &n) to get the number of bytes to read, if any. There -is- a call there, but it's only called in a case that doesn't apply to what we're looking for. I don't have the sources in front of me, so I can't be more specific. However, I have check into this last week and verified the oversight. The workaround is for your routine to do the said ioctl() (above) and returning if nothing's there to be read. But even if your routine just returns and does nothing else, you'll notice a dramatic increase in your cpu usage. If you are using pipes, then you're a little better off -- especially if you're just reading or writing (as opposed to reading -and- writing). When you're done sending/receiving data to/from the pipe, close the pipe and XtRemoveInput (xmh does this). (btw, be sure to pick up the dead child from the fork.) However, if you want to use this function to sit and wait for data to be put into a file, then until they fix the XtAddInput thing, I recommend that you use an alternate method -- use XtAddTimeOut and set it for every 1 second or so. Your callback for the timeout can do the ioctl() to see if there's any data to be read, and if so, manually call the same routine that you would have installed for XtAddInput(). Your cpu will be very grateful. dan