Marko Rauhamaa <ma...@pacujo.net> writes: > It would appear that disk I/O is considered nonblocking at a very deep > level: > * O_NONBLOCK doesn't have an effect > * a process waiting for the disk to respond cannot receive a signal > * a process waiting for the disk to respond stays in the "ready" state
You can handle those issues with AIO. It's open(2) that seems to have no asynchronous analog as far as I can tell. Actually, looking at the AIO man pages, it appears that the Linux kernel currently doesn't support it and it's instead simulated by a userspace library using threads. I didn't realize that before. But AIO is at least specified by POSIX, and there was some kernel work (io_setup(2) etc.) that may or may not still be in progress. It also doesn't have an open(2) analog, sigh. > On the networking side, there is also a dangerous blocking operation: > socket.getaddrinfo() (and friends). As a consequence, socket.bind(), > socket.connect() may block indefinitely. In fact, even asyncio's > BaseEventLoop.create_server() and BaseEventLoop.create_sonnection() may > block indefinitely without yielding. getaddrinfo is a notorious pain but I think it's just a library issue; an async version should be possible in principle. How does Twisted handle it? Does it have a version? I've just felt depressed whenever I've looked at any Python async stuff. I've written many Python programs with threads and not gotten into the trouble that people keep warning about. But I haven't really understood the warnings, so maybe they know something I don't. I just write in a multiprocessing style, with every mutable object owned by exactly one thread and accessed only by RPC through queues, sort of a poor man's Erlang. There's a performance hit but there's a much bigger one from using Python in the first place, so I just live with it. -- https://mail.python.org/mailman/listinfo/python-list
