fifo type files

Dan Mercer mercer at ncrcce.StPaul.NCR.COM
Wed Jan 10 04:59:58 AEST 1990


In article <1542 at lakesys.lakesys.com> davek at lakesys.lakesys.com (Dave Kraft) writes:
:I am interested in learning the uses for files made by                
:/etc/mknod <filename> p.  When you do a /bin/file <filename>, it comes back
:with <filename>:  fifo.  What can this type of file be used for?
: 
:Thanks in advance.
: 
:P.S. Please reply in email, as I do not always read this newsgroup.
: 
:Dave
:
:-- 
:davek at lakesys.lakesys.com <OR> uunet!marque!lakesys!davek
:-------------------------------------------------------------------------------
:"Empathy is sort of like telepathy's kid brother"
:  -- taken from "Stardance" by Spider and Jeanne Robinson

A FIFO is a named pipe - that is,  it is a file that acts like a pipe,
and a pipe that acts like a file.  Like a file,  it is opened by name.
Like a pipe,  it must be open at both ends to fully open.  

What can it be used for.  Well,  a pipe can be used to tie 2 related
processes together (where one proces is forked by a second,  or both
processes are forked by the same parent).  A named pipe can tie 2
unrelated processes together.  This can allow for some very potent
programming.

Consider the following example:
# 
# these instructions illustrate how to set up a background
# engine in a shell script

# first you'll need FIFOS - either pre-allocate them or allocate temporaries
# this code uses temporaries

ITMP=/usr/tmp/i.$LOGNAME
OTMP=/usr/tmp/o.$LOGNAME

rm -f $ITMP $OTMP 2>/dev/null
/etc/mknod $ITMP p  # input fifo for engine
/etc/mknod $OTMP p  # output fifo for engine

# start background engine and open $OTMP as new standard in

# bc is the interactive desk calculator - actually a front end to 
# dc which is forked and data is piped back and forth between the two

bc <$ITMP >$OTMP &
exec 3>$ITMP # utility channel to bc
exec 0<$OTMP # read output of bc

# send command to background engine
# if background engine is bc,  counters can be maintained
# echo "x = 1"
# echo "x = x + 1" or echo "++x"
#the second version returns the new value of x

for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
    do
    echo "2^$i = \c"
	echo "2^$i" >&3

	# read response

	read ans
	echo $ans
    done

# terminate background engine and remove fifos

echo "quit" >&3
rm -f $ITMP $OTMP

exit 0

# compare this code with the following

for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
    do
    echo "2^$i = `echo \"2^$i\" |bc`"
    done

# time values for 3 runs of each program on a lightly loaded NCR Tower 600
(Motorola 68020)

With background engine :

2^1 = 2                	2^1 = 2                	2^1 = 2                
-------                 -------                 -------                
2^15 = 32768           	2^15 = 32768           	2^15 = 32768           
                       	                       	                       
real        3.6        	real        4.4        	real        3.7        
user        0.3        	user        0.4        	user        0.4        
sys         1.1        	sys         1.2        	sys         1.2        

Without background engine:

2^1 = 2                	2^1 = 2                	2^1 = 2                
-------                 -------                 -------                
2^15 = 32768           	2^15 = 32768           	2^15 = 32768           
                       	                       	                       
real       15.7        	real       14.2        	real       14.6        
user        0.3        	user        0.4        	user        0.4        
sys         4.3        	sys         4.0        	sys         4.0        

I use this kind of program when manipulating large lists of
hexadecimal data.  If you find this useful,  I'd appreciate your
passing along the code you write if you think it might have wider
use.



I have another program called tvp.  Tvp gets started in background
on my first login to a system and stays up till I log off that terminal
(I am frequently logged on several terminals).  It is connected to
two fifos.  It reads a database file,  organizes the database in
memory,  then opens its input fifo.  Since the fifo is not open on
the other end,  the open blocks and the process sleeps.

When I go to program,  I enter vi.  I'll type a pattern,  engine
for instance,  then hit PF7.  PF7 takes the current line and writes
it to tvp's input fifo,  then open tvp's output fifo with a read
command.  The open blocks,  and vi sleeps.  Tvp wakes,  reads the input
fifo,  takes the pattern,  matches it to info in the database and
writes the data to the output fifo.  Then tvp returns to open the input
fifo again,  and again sleeps.

Vi wakes,  and places the data in the file.  Engine gets me the code
I detailed above for creating Bourne Shell background engines.  It
sure simplifies things.

Tvp is blazingly fast.  It can import the data so fast even a competent
typist can use it without skipping a beat.  And the database is easy
to maintain,  since it's a simple text file (if there is no match in
the database,  the lintlibs are examined,  allowing me instant access
to the format and syntax of all the standard function calls).

We developed a very complex systems analysis environment using vi
as a presentation services manager,  with an overlaying menuing
system,  and background database programs all tied together by
fifos.

If someone called up the menuing system,  he hit a PF key that invoked
a macro that read from an input FIFO.  The menuing system was sitting
blocked on the open of the FIFO.  The menuing system then displayed it's 
choices.  After a selection,  it opened an output FIFO and wrote the
request to a Parser/Analyzer,  which forked the appropriate subprogram,
received the answer by pipe, opened an output FIFO back to the menuing
program,  which wrote the answer to the originally opened FIFO.
If the menuing system was bypassed (by more advanced users),  the
request could be typed into the vi file,  a PF key struck,  and the
data written directly to the P/A request FIFO  and the answer read from the
P/A response FIFO.

-- 

Dan Mercer
Reply-To: mercer at ncrcce.StPaul.NCR.COM (Dan Mercer)



More information about the Comp.unix.questions mailing list