Donn Cave <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Rochester <[EMAIL PROTECTED]> wrote:
>
> > I just found out that the general open file mechanism doesn't work
> > for named pipes (fifo). Say I wrote something like this and it
> > simply hangs python:
> >
> > #!/usr/bin/python
> >
> > import os
> >
> > os.mkfifo('my fifo')
> >
> > open('my fifo', 'r+').write('some strings.')
> > x = os.popen('cat my fifo').read()
> >
> > print x
>
> 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).
> If you contrive to keep the file pointer around until after
> the reader has opened it, then you can read some data from
The problem is that the writer can never finish opening it; the
workaround is to have a separate process open it for reading first.
> it. (You can't read "all" the data, though - since you still
> have the file open, it has no end of file - so you can't
> solve the problem exactly as stated above.)
Actually, in CPython (1.5.2 to 2.5 included, at least), _IF_ open worked
normally then the file WOULD be closed by the statement
open('my fifo', 'r+').write('some strings.')
as the file object's reference counts drops to 0 at this statement's
end. (This would NOT necessarily happen in other Python
implementations, such as Jython or IronPython, but I suspect THOSE
implementations wouldn't have os.mkfifo...).
> And the odds are fair that when you get this working, you
> will run into some other inconvenient behavior. Named pipes
> are a little tricky.
Very -- particularly their blocking behavior at open (which appears to
have perhaps tricked you in this case).
Alex
--
http://mail.python.org/mailman/listinfo/python-list
