It was the code I meant, not the test. But I just tested your revised version, and now the unit tests succeed here as well. Thanks.
The master should be non blocking indeed. I my project i called ""io.open(self.master, 'wb', 0)"" Something related about blocking vs. non blocking. I don't know how these file descriptors work exactly. But I was now also able to use connect_read_pipe to read from stdin which was really nice for me. (I really didn't like the executor solution that much.) However, if you make stdin non blocking, stdout will automatically also become non blocking. But writing to non blocking stdout seems like a bad idea, (you get "write could not complete without blocking" errors everywhere.) So what I do right now is to make stdout blocking again before writing, during a repaint of the app, and unblocking after writing. (Because this is all in the same thread as the event loop, it will be non blocking again when we get there.) It works nice, but what would be nice was to have a _sec_blocking method available in unix_events which is symmetrical. (I why wouldn't we make them public?) Le mardi 7 janvier 2014 05:54:57 UTC+1, Guido van Rossum a écrit : > > 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] <javascript:>> 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) >
