🚀 go-pugleaf

Submitted-by: henry@zoo.toronto.edu (Henry Spencer)

>Submitted-by: ast@cs.vu.nl (Andy Tanenbaum)
>There is no place in the i-node to keep track of the current file position,
>and copying the FIFO to shift everything down 5 bytes doesn't sound like
>much fun.  Trying to figure out where the start of data is from the parent's
>file pointer doesn't help, and besides, if the parent had closed too, that
>wouldn't be there.  How is this normally implemented?

Note that 6.3.1.2 says that if all file descriptors associated with a FIFO
have been closed, any remaining data goes away.  The issue arises only if
somebody has kept the FIFO open, so the usual approach is for the kernel
to retain some extra information in core for an *open* FIFO.  Andy is
correct that file pointers aren't useful, if only because there can be
more than one of them if several processes are involved; the extra
information has to be associated with the (in-core) inode, not with a
particular customer.
-- 
GCC 2.0 is to C as SVR4 is to Unix.     | Henry Spencer @ U of Toronto Zoology
                             -Dick Dunn |  henry@zoo.toronto.edu  utzoo!henry


Volume-Number: Volume 27, Number 76