On 2/14/12 4:04 PM, Øyvind Hvidsten wrote:
> Please correct any mistakes in my wording, as I would very much like to be
> able to use the correct terms when describing this. Also, please ask if
> anything is unclear :)
>
> My problem occurs when I do the following:
> mkfifo foo; exec 3<"foo"; echo done
>
> This blocks on the exec statement, and never reaches the echo statement,
> even though I don't think I've asked bash to read from that file descriptor
> (yet). The plan was to use "read -t 0 <&3" at a later stage to check if
> something is available there.
This is from the Posix description of `open'. Bash uses O_WRONLY and
O_RDONLY when opening files for output or input, respectively (> and <).
It does not use O_NONBLOCK.
==========
When opening a FIFO with O_RDONLY or O_WRONLY set:
If O_NONBLOCK is set, an open() for reading-only shall return without
delay. An open() for writing-only shall return an error if no process
currently has the file open for reading.
If O_NONBLOCK is clear, an open() for reading-only shall block the
calling thread until a thread opens the file for writing. An open() for
writing-only shall block the calling thread until a thread opens the file
for reading.
==========
exec 3<>foo works because it uses O_RDWR. This is just how FIFOs work.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
