Donn Cave <[EMAIL PROTECTED]> wrote: ... > > 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.
...and produces "undefined behavior" according to the manpage. > 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!] I have no problems using named pipes _according to their documentation_ (so, in particular, no O_RDWR opening, and acceptance of their thread-blocking behavior on O_RDONLY and O_WRONLY opening; I have no experience with opening named pipes in non-blocking mode). Alex -- http://mail.python.org/mailman/listinfo/python-list