Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Marko Rauhamaa <marko@pacujo.net>
Newsgroups: comp.lang.python
Subject: Re: asyncio - run coroutine in the background
Date: Sat, 20 Feb 2016 10:13:11 +0200
Organization: A noiseless patient Spider
Lines: 51
Message-ID: <87oabbpzoo.fsf@elektro.pacujo.net>
References: <mailman.131.1455518141.22075.python-list@python.org> <8737sumpjl.fsf@elektro.pacujo.net> <mailman.132.1455520607.22075.python-list@python.org> <87h9ha8lt0.fsf@jester.gateway.pace.com> <CAPTjJmoWUDfcOe3OCaMK7=zDtW3QzS+7hqUG6DoYZ2AbqzJBUw@mail.gmail.com> <mailman.166.1455628969.22075.python-list@python.org> <87d1rwpwo2.fsf@elektro.pacujo.net> <n9vc4j$n89$1@ger.gmane.org> <CAKF=+dhXZ=yax8STAWr_gjX3Tg8yUjPRJG-7yM2_bRV2Kxm3Jg@mail.gmail.com> <mailman.173.1455636082.22075.python-list@python.org> <87r3gc608i.fsf@elektro.pacujo.net> <871t877ru6.fsf@jester.gateway.pace.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org; posting-host="b7cb1518d23ec19d482dcc9c31d30fdd"; logging-data="4053"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/wcHSAjQmnncrs0GfyvECt"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
Cancel-Lock: sha1:6kcW+q2AGy8N+HVcKqpklM6Vkvs= sha1:Ap+Uv/S5NfSegw53a552ZlsxieY=
Xref: csiph.com comp.lang.python:103248

Paul Rubin <no.email@nospam.invalid>:

> Marko Rauhamaa <marko@pacujo.net> writes:
>> "Frank Millman" <frank@chagford.com>:
>>> I would love to drive the database asynchronously, but of the three
>>> databases I use, only psycopg2 seems to have asyncio support.
>> Yes, asyncio is at its infancy. There needs to be a moratorium on
>> blocking I/O.
>
> Unfortunately there appears to be no way to open a file in Linux
> without at least potentially blocking (slow disk or whatever). You
> need separate threads or processes to do the right thing.

I have been wondering about the same thing. 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

Note that

 * most disk I/O operates on a RAM cache that is flushed irregularly

 * memory mapping and swapping make disk I/O and RAM access two sides of
   the same coin

 * page faults can turn any assembly language instruction into a
   blocking disk I/O operation

 * ordinary disks don't provide for much parallelism; processes are
   usually serialized for disk I/O

If the file system happens to be NFS, a networking issue may paralyze
the whole system.

...

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.

SEE ALSO
    getaddrinfo_a(3)


Marko