Unix Programming - named pipes block ...when?

Author

named pipes block ...when?

heepa9@yahoo.com

2005-12-12, 7:15 pm

Hi all,

I'm seeing some contradictory behavior when I use named pipes
with Linux 2.4.

Scenario 1 : no problematic blocking occurs

Process A creates a pipe using system("mkfifo /tmp/pipename")
Process A opens and writes to that pipe, then closes it.
Process B opens the pipe and reads from it.
OK

Scenario 2: problematic blocking occurs.

Process B creates a pipe using system("mkfifo /tmp/pipename")
Process A opens that pipe for writing, then blocks until there's a
reader.
However Process B blocked when it spawned Process A.
- deadlock -

My question is, is it normal and expected that blocking would
occur when a process wants to open-for-writing?

This also happens when I go:

mkfifo /tmp/foo
echo fubar > /tmp/foo

Thanks.

Gordon Burditt

2005-12-13, 4:13 am

>> Scenario 2: problematic blocking occurs.
>
>Yes. A pipe is a connection between two processes, a writer and a
>reader. If there's no reader, where does the data that the writer sends
>go? If you want to write something without waiting for a reader, you
>should use an ordinary file, not a pipe.

If you don't like that behavior of a named pipe, open it for O_RDWR.
In that case, there *is* a reader (even if that reader will never
read anything) and no wait on the open.

>Check your open(2) man page, it may even mention that opening a named
>pipe for writing will block until another process opens it for reading,
>unless you use the O_NONBLOCK option.

Beware that trying to fork a child with two pipes for stdin and
stdout is filled with opportunities to deadlock. Ways out include:
- Both ends need to fflush() after every most write.
- Close off unused pipe ends! Open 2 (unnamed) pipes, then fork(),
and you've got 8 pipe ends, 4 of which need to be closed. An
extra write end open means you NEVER see EOF.
- The parent needs to use select() or poll() or non-blocking I/O
to monitor both the in and the out pipes.
- Sometimes the child's protocol makes it easier: for example,
sort(1) produces no output until it has read all its input.

Gordon L. Burditt

Michael Kerrisk

2005-12-13, 4:13 am

On Tue, 13 Dec 2005 05:27:25 -0000, gordonb.nhk8r@burditt.org (Gordon
Burditt) wrote:

Why not just use mkfifo(3)?

Also, if this is a serious application, don't use /tmp -- you open
yourself up for denial-of-service attacks by creating files in a
publicly writable directory like /tmp.
[color=darkred]
>
>If you don't like that behavior of a named pipe, open it for O_RDWR.
>In that case, there *is* a reader (even if that reader will never
>read anything) and no wait on the open.

This works on many implementations, but is non-standard (SUSv3
does not specify this feature). The portable, standard way of doing
this is to do two opens in the same process: the first uses O_RDONLY |
O_NONBLOCK, the second uses just O_WRONLY.

But, as Barry said, mostly you want the defalt behaviour: opening a
FIOF O_WRONLY blocks until another process opens O_RDONLY, and vice
versa.

Cheers,

Michael

Barry Margolin

2005-12-13, 8:14 am

In article <1134404125.448527.257180@g49g2000cwa.googlegroups.com>,
"heepa9@yahoo.com" <heepa9@yahoo.com> wrote:

> Hi all,
>
> I'm seeing some contradictory behavior when I use named pipes
> with Linux 2.4.
>
> Scenario 1 : no problematic blocking occurs
>
> Process A creates a pipe using system("mkfifo /tmp/pipename")
> Process A opens and writes to that pipe, then closes it.
> Process B opens the pipe and reads from it.
> OK
>
> Scenario 2: problematic blocking occurs.
>
> Process B creates a pipe using system("mkfifo /tmp/pipename")
> Process A opens that pipe for writing, then blocks until there's a
> reader.
> However Process B blocked when it spawned Process A.
> - deadlock -
>
> My question is, is it normal and expected that blocking would
> occur when a process wants to open-for-writing?

Yes. A pipe is a connection between two processes, a writer and a
reader. If there's no reader, where does the data that the writer sends
go? If you want to write something without waiting for a reader, you
should use an ordinary file, not a pipe.

Check your open(2) man page, it may even mention that opening a named
pipe for writing will block until another process opens it for reading,
unless you use the O_NONBLOCK option.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

heepa9@yahoo.com

2005-12-13, 7:04 pm

I was hoping the "where does it go" question would
be answerable with "it's cached in memory until
read out by some process", so that a pipe could serve
as a serial storage mechanism e.g. for sound players.

heepa9@yahoo.com

2005-12-13, 7:04 pm

>Why not just use mkfifo(3)?

I'm doing it from an old, Fortran-like language.
However I could write a C program to make that call
and just spawn that.

Sponsored Links