On Mon, Jan 6, 2014 at 10:57 PM, Jonathan Slenders <[email protected]> wrote: > 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.
OK, but I'm not at all convinced that catching EIO and treating it the same as EOF is correct. I don't even understand why I get that EIO. Could you show me some synchronous code (maybe using threads) showing how pyts are expected to work? > The master should be non blocking indeed. I my project i called > ""io.open(self.master, 'wb', 0)"" There seems to be confusion here -- the 0 means non-*buffering*, it has no effect on *blocking*. > Something related about blocking vs. non blocking. I don't know how these > file descriptors work exactly. Then how can you write working code using them? (Not a rhetorical question.) > But I was now also able to use > connect_read_pipe to read from stdin which was really nice for me. Hm, this is really falling quite far outside the intended use case for asyncio. (Though well within that for the selectors module.) > (I really didn't like the executor solution that much.) I'm not aware of that solution -- is it in the docs somewhere? > However, if you make stdin non > blocking, stdout will automatically also become non blocking. Yeah, I see that too. I can't explain it; I suspect it's some obscure implementation detail of tty (or pty) devices. :-( > But writing to > non blocking stdout seems like a bad idea, (you get "write could not > complete without blocking" errors everywhere.) So wrap a transport/protocol around stdin/stdout.That would seem to be the asyncio way to do it. You should probably wrap those in a StreamReader/StreamWriter pair -- the source code (streams.py) shows how to create those by hand, which is an intended use. > 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.) Eew! :-( > It works nice, but what would be nice was to have a _set_blocking method > available in unix_events which is symmetrical. (I why wouldn't we make them > public?) By the time you are passing your own file descriptors you should be mature enough to know how to make them non-blocking. Plus this is all UNIX-specific... Plus, create_pipe_transport() already calls it for you. Overall, perhaps you should just use the selectors module instead of asyncio? You might be happier with that... -- --Guido van Rossum (python.org/~guido)
