Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!haven!ncifcrf!nlm-mcs!adm!xadmx!konczal@mail-gw.ncsl.nist.gov
From: konczal@mail-gw.ncsl.nist.gov (Joe Konczal)
Newsgroups: comp.unix.wizards
Subject: how do I know when a process wants data
Message-ID: <21165@adm.BRL.MIL>
Date: 16 Oct 89 16:37:14 GMT
Sender: news@adm.BRL.MIL
Lines: 32


>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