Yury Selivanov added the comment:
> I should have known better that I wasn't going to find a bug in python :)
We have a lot of bugs, as any other software :) Don't be afraid to open issues.
I'll close this bug, feel free to re-open.
--
resolution: -> not a bug
stage: -> resolved
st
skorpeo added the comment:
yes, in this case they were meant to stay open to write and read multiple
messages. I was hoping to read data when it is available, the other work
around was to specify n, but that also blocked once there was no more data
to be fetchedEither way I will stick to qu
Yury Selivanov added the comment:
> You are also correct that there is no clean up for closing the pipes.
It's not just about the cleanup. If you don't close the pipes, they will be
open forever, so there will be no EOF for which read(-1) will wait forever.
--
___
skorpeo added the comment:
Yes makes sense, it could be another bug with TTY or just my error and I
did preface that I am submitting this humbly. You are also correct that
there is no clean up for closing the pipes.
On Mon, May 28, 2018 at 1:45 AM, Yury Selivanov
wrote:
>
> Yury Selivanov a
Yury Selivanov added the comment:
"if not block:" means EOF and replacing it with "if len(block) < self._limit:"
would break everything.
There might be another bug here (with TTY) or, maybe, there's a bug in
pty_test.py. For example, I don't see how you closing reader_pipe or
writer_pipe.
New submission from skorpeo :
I humbly submit what I think may be a bug in the asyncio.StreamReader.read()
function. When n=-1 is supplied and the data is less than self._limit the read
function creates a future and never wakes it up. I believe the culprit is
https://github.com/python/cpytho
