I looked into this. The tests pass on OSX (10.8), but fail indeed on my Ubuntu VM. I can make them pass by catching the OSError with errno==EIO and pretending it's an EOF *and* using test_utils.run_until() instead of run_briefly() in the test (in both places).
Here's a revised version of the patch: http://codereview.appspot.com/48350043 I also folded some long lines and made master_read_obj unbuffered. I also think that technically the master should be set in nonblocking mode (using e.g. unix_events._set_nonblocking()) but it doesn't seem to affect the test. I also wonder if the test ought to be in test_unix_events.py instead of in test_events.py. When you wrote "That works, but [...]" what did you mean by "that works"? What code did you run to verify it? (Since clearly the test you wrote *doesn't* work. :-) On Sun, Jan 5, 2014 at 3:01 AM, Jonathan Slenders <[email protected]> wrote: > I created a patch: https://codereview.appspot.com/38500044/ > > That works, but the unit test still fails, I'm not sure how to correctly > close this pipe. > > > [tulip] > python runtests.py > Skipping 'test_windows_events': Windows only > Skipping 'test_windows_utils': Windows only > ...................................................................................................................... > ............................Fatal error for > <asyncio.unix_events._UnixReadPipeTransport object at 0x7fb6a5951e10> > Traceback (most recent call last): > File "/home/jonathan/hg/tulip/asyncio/unix_events.py", line 204, in > _read_ready > data = os.read(self._fileno, self.max_size) > OSError: [Errno 5] Input/output error > Exception in callback <bound method > _UnixReadPipeTransport._call_connection_lost of > <asyncio.unix_events._UnixReadPipe > Transport object at 0x7fb6a5951e10>> (OSError(5, 'Input/output error'),) > Traceback (most recent call last): > File "/home/jonathan/hg/tulip/asyncio/events.py", line 38, in _run > self._callback(*self._args) > File "/home/jonathan/hg/tulip/asyncio/unix_events.py", line 240, in > _call_connection_lost > self._protocol.connection_lost(exc) > File "tests/test_events.py", line 135, in connection_lost > assert self.state == ['INITIAL', 'CONNECTED', 'EOF'], self.state > AssertionError: ['INITIAL', 'CONNECTED'] > > > > > > Le dimanche 5 janvier 2014 07:51:58 UTC+1, Guido van Rossum a écrit : >> >> Why do you report a bug using a rhetorical question? :-) >> >> Please file a bug either at http://code.google.com/p/tulip/issues/list >> or bugs.python.org (the former gets my attention, the latter might get >> other developers' attention). If you want to submit a patch with a >> test that would be super. (See >> http://code.google.com/p/tulip/wiki/Contributing .) >> >> On Sat, Jan 4, 2014 at 10:31 AM, Jonathan Slenders >> <[email protected]> wrote: >> > Hi all, >> > >> > Why does loop.connect_read_pipe not support the pipes that openpty() >> > creates, but is does for os.pipe() >> > >> > master, slave = os.openpty() >> > shell_out = io.open(master, 'rb', 0) >> > transport, protocol = yield from loop.connect_read_pipe(MyProtocol, >> > shell_out) >> > >> > >> > In unix_events.py, there's the following check that fails. >> > >> > if not (stat.S_ISFIFO(mode) or stat.S_ISSOCK(mode)): >> > >> > >> > I think it should be something like this: >> > >> > if not (stat.S_ISFIFO(mode) or stat.S_ISSOCK(mode) or >> > stat.S_ISCHR(mode)): >> > >> > >> > I tried this patch and it resolves the issue for me. Correct me if I'm >> > wrong, but I don't think there is any reason to block character devices >> > like >> > this. Actually they're not that different from a unix pipe. >> > >> > >> > For those interested in my use case: >> > I'm building something like "tmux" or "gnu screen", but in Pure Python. >> > I >> > use the "pyte" library as output interpreter, but will write a custom >> > renderer. >> > Calling the subprocess_exec wrapper does not work, because it uses >> > normal >> > pipes, while I want the programs that run to be aware that they are >> > running >> > in a real pseudo terminal. >> > >> > >> > Cheers, >> > Jonathan >> >> >> >> -- >> --Guido van Rossum (python.org/~guido) -- --Guido van Rossum (python.org/~guido)
