[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-bash] Creating an anonymous pipe for later use
From: |
Russell Lewis |
Subject: |
Re: [Help-bash] Creating an anonymous pipe for later use |
Date: |
Thu, 09 Oct 2014 14:39:30 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 |
They work according to spec - I'm not claiming that they are buggy. But
they have more pitfalls than anonymous pipes.
Key ones I stumbled on:
1) Need to clean up filesystem artifacts; hard to do
this promptly without races (removing the file
before it is used)
2) Can't open just one side of a pipe - open() will
block. So kicking off two commands from the same
script, and connecting them with a named pipe, is
possible (but very hard to do without deadlock)
3) A child process cannot open /dev/fd/0 (to get a dup
of the parent script's stdin) if stdin is a named
pipe; open() will block (on Linux). On other *NIXes,
I have read that the open() will just dup() the file
descriptor (which is what I wanted) - Linux works
differently.
For the record, the way to kick off two commands from the same parent
script, connected through a named pipe, without either races or
deadlock, is as follows:
tmp=$(mktemp -u)
mkfifo $tmp
cmd1 >$tmp & # opens the pipe in the child process.
{ cmd2 & } <$tmp # opens the pipe in the parent process.
# open() blocks until both sides have
# started it.
rm $tmp
Ick.
Russ
On 10/09/14 13:43, Bob Proulx wrote:
Russell Lewis wrote:
Linux's support for named pipes is less robust than its support for
anonymous pipes.
What isn't robust about them? I have used them extensively and I
haven't found anything not robust about them. Therefore I suspect
simply a misunderstanding of some sort.
I've done a lot of experimentation with them, and have come to the
conclusion that I should use anonymous pipes if at all possible. (I
can give details in a separate email if anyone is interested.)
Bob