X-Git-Url: http://git.tuebingen.mpg.de/?a=blobdiff_plain;f=Unix_Concepts.m4;h=fb3a122fcda0136dbebdd16b93646c681ee1be43;hb=HEAD;hp=be51cc9096ad4af3e9bb5721e1bd67774f776be6;hpb=c03deda9d239c1ade70406414855b34808b2d3a4;p=aple.git

diff --git a/Unix_Concepts.m4 b/Unix_Concepts.m4
index be51cc9..fb3a122 100644
--- a/Unix_Concepts.m4
+++ b/Unix_Concepts.m4
@@ -557,8 +557,8 @@ EXERCISES()
 HOMEWORK(«
 
 Think about printers, sound cards, or displays as a file. Specifically,
-describe what <code>open, read</code>, and <code>write</code> should
-mean for these devices.
+describe what <code>open</code>, <code>read</code>, and <code>write</code>
+should mean for these devices.
 
 », «
 
@@ -570,9 +570,10 @@ printers could return the number of paper trays, the amount of toner
 left etc. Writing to the file descriptor would cause output on the
 device. This would mean to print the text that is written, play the
 audio samples, or show the given text on the display. The point to
-take away is that the <code>open, read, write</code> interface is a
-generic concept that works for different kinds of devices, not only
-for storing data in a file on a hard disk.
+take away is that the <code>open</code>, <code>read</code>,
+<code>write</code> interface is a generic concept that works for
+different kinds of devices, not only for storing data in a file on a
+hard disk.
 
 »)
 
@@ -1790,8 +1791,7 @@ SUBSECTION(«Pipes and Redirections»)
 
 <p> The <code>pipe(2)</code> system call takes no arguments and
 creates two file descriptors for the calling process which are tied
-together as a unidirectional first in, first out data channel that
-works just like a fifo, but without any files being involved. One
+together as a unidirectional first in, first out data channel. One
 file descriptor is the <em>read end</em> of the pipe, the other is
 the <em>write end</em>. Data written to the write end is buffered by
 the kernel and can be obtained by reading from the read end. </p>
@@ -1803,6 +1803,18 @@ a copy of both pipe file descriptors. Hence the parent process can
 communicate with the child by writing a message to the write end of
 the pipe for the child to read. </p>
 
+<p> This approach depends on file descriptor inheritance across
+<code>fork(2)</code>, so it does not work in the situation
+where neither process is an ancestor of the other. Files of
+type <em>fifo</em> (named pipes) overcome this restriction. To
+establish a connection between two <em>unrelated</em> processes,
+both processes call <code>open(2)</code> to obtain a file
+descriptor which is associated with the fifo. One process passes
+the <code>O_WRONLY</code> flag to open the file for writing while
+the other passes <code>O_RDONLY</code> to open it for reading. The
+two processes may then communicate in the same way as with the
+<code>pipe(2)/fork(2)</code> approach. </p>
+
 <p> The POSIX <code>dup(2)</code> and <code>dup2(2)</code> system
 calls allow a process to manipulate the entries of its file descriptor
 array. In particular the standard file descriptors 0, 1, and 2 can be
@@ -1827,12 +1839,6 @@ with <code>wc(1)</code>. Since <code>ls(1)</code> writes to stdout
 and <code>wc(1)</code> reads from stdin, <code>wc(1)</code> processes
 the output of <code>ls(1)</code>. </p>
 
-<p> Note that this trick does not work to establish a connection
-between two <em>existing</em> processes because it depends on file
-descriptor inheritance across <code>fork(2)</code>. In the general
-case one has to fall back to sockets or fifos to create the data
-channel. </p>
-
 SUBSECTION(«Stdio»)
 
 <p> The POSIX standard requires a compliant Unix system to provide