cjsv@cs.adfa.oz.au (Christopher J S Vance) (10/09/89)
I want to run a process (call it dexec) which fork's and exec's an ordinary Unix process (call it X) using a file descriptor shared with dexec. I want dexec to be notified that X is blocked waiting for input from the shared fd, but cannot expect that X even knows anything is happening. In particular, I cannot compile X, but can compile dexec. The assumption is that dexec can perform some operation to make data appear on the shared fd (although dexec won't be reading this data itself). Another reason for sharing the fd is that I want dexec to know how many characters are left on the fd when X terminates. What mechanism(s) should/can I use to do this? I would rather not poll, but it seems that select does the exact opposite of what I want, since I want to be notified when there is *no* data to read. What are the exceptional conditions alluded to in the documentation for select(2)? Might these help me? In which case, where are they documented? I am running several different varieties of Berklix, as hacked by Pyramid (4.0, 4.4), Sun (3.5, 4.0.3), and Convex (?), and am after a generic solution, because it's supposed to be part of a distributed execution system. Thanks for all responses.
perry@ccssrv.UUCP (Perry Hutchison) (10/12/89)
In article <511@ccadfa.adfa.oz.au> cjsv@cs.adfa.oz.au (Christopher J S Vance) writes: + I want to run a process (call it dexec) which fork's and exec's an + ordinary Unix process (call it X) using a file descriptor shared with + dexec. I want dexec to be notified that X is blocked waiting for input + from the shared fd ... Would it work to make like ps(1) and read /dev/kmem? I suppose that's polling of a sort, but short of kernel hacking I don't know what else would work in the general case. If you know enough about X, you could do like dbx(1) and set breakpoints in X whenever it's about to read.
konczal@mail-gw.ncsl.nist.gov (Joe Konczal) (10/16/89)
>From: Perry Hutchison <perry@ccssrv.uucp> >Date: 12 Oct 89 05:07:46 GMT > >In article <511@ccadfa.adfa.oz.au> cjsv@cs.adfa.oz.au (Christopher J S Vance) >writes: > >+ I want to run a process (call it dexec) which fork's and exec's an >+ ordinary Unix process (call it X) using a file descriptor shared with >+ dexec. I want dexec to be notified that X is blocked waiting for input >+ from the shared fd ... > >Would it work to make like ps(1) and read /dev/kmem? I suppose that's polling >of a sort, but short of kernel hacking I don't know what else would work in >the general case. If you know enough about X, you could do like dbx(1) and >set breakpoints in X whenever it's about to read. It seems to me that reading /dev/kmem would be more difficult and less portable than using asynchronous I/O and signals. In 4.3 BSD you could use `ioctl' to set the NDELAY and ASYNC flags so that an attempt to read on the shared fd that normally would block will return the EWOULDBLOCK error, and when successful reading becomes possible `X' will recieve a SIGIO signal. Then you could signal `dexec' when read returns with EWOULDBLOCK, and `X' could do something useful or just sleep while it waits for a SIGIO signal. Doesn't System V or other popular types of UNIX also provide asynchronous I/O and user defined signals, or some kind of substitute? -- Joe Konczal