Re: Operations permitted on a pipe

Jesse Pollard (pollard@tomcat.admin.navo.hpc.mil)
Mon, 20 Sep 1999 13:58:22 -0500 (CDT)


>> I'd like to know which file operations are permitted on a pipe created
>> by the corresponding system call: Is it possible (and legal) to get the
>> number of bytes in the pipe using lseek and is there a way to peek into
>> the pipe? Is the pipe disposed when one of the two handles is closed,
>> and what is the state of the other handle then?
>
>I'd like to know if a program can create a pipe (well duh <g>) and listen on
>it to write out some data, close it and re-open it (and do the same thing
>all over again). When I opened a pipe in non-block mode, I couldn't write
>to it and it would always be ready for write.
>
>To your question, I don't believe you can lseek it or anything, IIRC, it
>acts like a set of descriptors you get when using pipe(2) except it is
>opened instead of using pipe.

A pipe system call returns two fd's, one for write, one for read. The
normal way to use a pipe is for a fork to be done:
the parent closes one of the fd's (say the read fd).
the child closes the other fd (the write).

The parent can then write on the remaining fd.
The child can read from its remaining fd.

Seek/lseek... cannot be done, there is no file positioning available.

It is possible to perform ioctl functions on the pipe. The one I have
used most often is FIONREAD. The sample above can do this to determine
how many bytes are in the pipe, without actually reading the pipe.
(I believe there is a FIONWRITE to determine how many bytes are available
for writing without blocking).

This tends to be done for X applications - the pipe is made one of
the X events. When data is available for reading, the event dispatches
to a routine. The routine then determines how many bytes are there,
processes only that many, and returns to the event loop. If the routine
tries to read more than the available bytes, it will block (unless IONBLOCK
is done).

The same thing occurs with fifos - named pipes. The difference is that
the pipe does not have to be created by a parent process and shared with
subprocesses - A single reader process can start, and will wait until
something is written to the fifo - the reader can then read data.

For a bi-directional pipe usage (without deadlock) use a socket.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/