programming with FIFO's
Leslie Mikesell
les at chinet.chi.il.us
Sat Mar 2 15:53:13 AEST 1991
In article <26179 at adm.brl.mil> ANNEKE%HUTRUU54.BITNET at cunyvm.cuny.edu (Anneke Sicherer-Roetman) writes:
>In programming a spectrometer controller program I need the following:
>- a spectrometer control program that runs as a detached continous
> process. This has monitoring and regulating tasks but meanwhile
> every few seconds has to find out if another process (see below) is
> talking to it.
>- a terminal control program that is activated only when a researcher
> wants to tell the spectrometer something or read some message from it.
> This terminal control program, when activated from the system prompt,
> has to continually listen to the spectrometer program if it sends
> a message but meanwhile it must be able to take keyboard input and
> send this to the spectrometer control program. After he has done
> what he wanted to do the researcher exits from the terminal control
> program so that his terminal gets free for other things again.
>This I wanted to implement with two FIFO's on either side. But my problem
>is that NO FIFO read or write call may block until the other side listens
>or talks because both programs have other things to do as well. When I
>open the FIFO's with NO_DELAY I invariably get a No such device error on
>our System V machine. Our BSD 4.3 machine however obeys an
>open call with RDONLY|NODELAY so that things start to work. How can I
>get this to work on a System V machine, because that really is the
>machine the programs have to operate on?
Opening a FIFO is supposed to block if there is no process on the
other end, so setting O_NDELAY makes the open fail. You can either
let the open wait until the other process is also running, then use
fcntl() to set O_NDELAY, or just open both ends for read/write even
though each program will only do one or the other.
I'd probably run 3 programs and avoid the need to do non-blocking reads,
though. One process reads from device, encapsulates data and writes
to FIFO. One process reads from terminal, encapsulates data and
writes to FIFO. Daemon program reading FIFO can write directly to
device to control it, and can either write directly to the terminal
or you can provide a return FIFO for the terminal handling program
to access. This way all the reads can block until some data is
present. The programs writing to the FIFO need to provide enough
additional information to identify where the input came from and
must either use fixed length write()s or provide a length field
at the beginning. Also, all related info must be written to the
FIFO in a single write() to avoid interleaving input from different
sources. If throughput is important, the reading process can do
fairly large read()s and sort out the results from its buffer.
Les Mikesell
les at chinet.chi.il.us
More information about the Comp.unix.questions
mailing list