Paul Rubin <no.email@nospam.invalid>:
> Marko Rauhamaa <ma...@pacujo.net> writes:
>> "Frank Millman" <fr...@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
--
https://mail.python.org/mailman/listinfo/python-list
