asyncio - run coroutine in the background

Paul Rubin no.email at nospam.invalid
Sat Feb 20 03:37:08 EST 2016


Marko Rauhamaa <marko at 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.



More information about the Python-list mailing list