how do I know when a process wants data

Joe Konczal konczal at mail-gw.ncsl.nist.gov
Tue Oct 17 02:37:14 AEST 1989


>From: Perry Hutchison <perry at ccssrv.uucp>
>Date: 12 Oct 89 05:07:46 GMT
>
>In article <511 at ccadfa.adfa.oz.au> cjsv at 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



More information about the Comp.unix.wizards mailing list