Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uunet!midway!clout!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.unix.programmer
Subject: Re: Using select on FIFO's
Message-ID: <1991Jun04.225210.8567@chinet.chi.il.us>
Date: 4 Jun 91 22:52:10 GMT
Article-I.D.: chinet.1991Jun04.225210.8567
References: <BLARSEN.91May30090732@spider.uio.no> <1991May30.165554.4079@chinet.chi.il.us> <2729@root44.co.uk>
Distribution: comp
Organization: Chinet - Chicago Public Access UNIX
Lines: 44

In article <2729@root44.co.uk> gwc@root.co.uk (Geoff Clare) writes:

>Although this works on most if not all current UNIX systems, it's not
>required by POSIX, so applications using this method may not work
>on some future systems.  For maximum portability to current and
>future systems, I recommend using the following method to open both
>sides of a FIFO to do blocking I/O:
>
>	fd_rd = open("FIFO", O_RDONLY|O_NONBLOCK);
>	fd_wr = open("FIFO", O_WRONLY);
>	flags = fcntl(fd_rd, F_GETFL);
>	fcntl(fd_rd, F_SETFL, flags & ~O_NONBLOCK);

Is it required to work when the process opens with one fd for
reading and a different one for writing?  I do that in shell
scripts to make them block when no one else is writing to
the FIFO:
---simple shell script server---
setup code...
while read CMD P1 P2 P3 P4 P5 P6
do
 case "$CMD" in
  STOP)
    exit 0
     ;;
   whatever else...
  esac
done <FIFO 4>FIFO

I just start one of these in the background to schedule jobs and
other scripts periodically echo commands to it.  IMHO FIFO's would
be pretty useless if you couldn't get reasonable blocking to
happen from a shell script.  I also use the non-blocking mode
that happens after the first writer closes in some other scripts.
The setup is similar except for the 4>FIFO and a calling script
always writes a dummy command after starting the daemon script in
the background.  In this case the daemon program has something to
do in the body of the loop and only checks periodically for controlling
commands.  If nothing has been written since the last time around
the read returns EOF (nothing) and the loop continues.
Is this behaviour portable?

Les Mikesell
  les@chinet.chi.il.us