Python open a named pipe == hanging?

[Donn Cave]

In article <1hjpqc2.1nbzu37nfvvkuN%aleax at mac.com>,
 aleax at mac.com (Alex Martelli) wrote:

> Donn Cave <donn at u.washington.edu> wrote:
>    ...
> > > > I believe your problem is that, by the time you open the
> > > > pipe for read, it has already been closed by its writer.
> > > 
> > > Hmmm, no: the problem is, he never opens the pipe for write, because the
> > > open blocks (will not proceed until somebody opens the fifo for reading,
> > > which in turn won't happen here because the open blocks).
> > > 
> > > Try:
> > > 
> > > a = open('my_fifo', 'w')
> > > b = os.popen('cat my_fifo')
> > > a.write ...
> > > a.close()
> > > c = b.read()
> > > 
> > > this STILL doesn't work, since the very first statement blocks.  (I've
> > > also removed the 'r+' mode in favor of 'w', since opening a FIFO for
> > > reading AND writing produces undefined behavior, at least in all Unix
> > > versions and variants I'm familiar with).
> > 
> > But it does work.  I edited that excerpt only to complete
> > missing parts, and ran it on MacOS X and GNU Linux.
> > 
> > import os
> > f = '/tmp/r'
> > try:
> >         os.unlink(f)
> > except:
> >         pass
> 
> You forgot to add os.mkfifo(f) here -- so you're writing and reading a
> perfectly ordinary file... of course *that* gives no problems!-)

Of course you're right about that, and with that fixed we
see that you're right, the open blocks.  In order to avoid
that, you have to open "r+", which after all is what the
original post proposed to do.

os.mkfifo(f)
a = open(f, 'r+')
a.write('chunks\n')
b = os.popen('cat %s' % f)
a.close()
c = b.readline()
print repr(c)

And again, if the close() moves up before the "cat", there's
no data - the read end has to open before the write end closes.

But I cheated when I replaced read() with readline().  The read end
("cat") doesn't detect the end of file, when there are two processes
involved.  On NetBSD, when the child process closes the write
descriptor, that operation doesn't entirely succeed and the file
descriptor is left in a `no more information' state.  On Linux,
one doesn't see that, but the result is the same.  In any case, a
stream that can't have an end is not going to be very satisfactory.
[I don't know why I get tangled up in these named pipe problems,
when I know better myself than to use them!]

   Donn Cave, donn at u.washington.edu