libaio 0.9.3

Linux AIO简介

在发送或接收数据时，开发者通常会面临的一个典型问题是知道何时操作会完成，以便程序可以继续执行。

• read/write/recv/send：在发生事件之前阻塞

• 相同，在非阻塞文件描述符上：出错而不是阻塞，开发者必须以某种方式实现重试，并且最终可能会浪费CPU时间，只是反复提交相同的操作。

• select/poll/epoll：内核告诉程序何时（重新）提交操作不会阻塞（如果开发者小心不要有竞争的IO源）

AIO是下一级：应用程序表达了一些IO操作将在文件描述符接受时发生的意图，并提供相应的缓冲区给内核。与select/poll/epoll相比，这避免了在操作可能发生时对用户空间的一次往返

• 内核发送通知（例如，fd可读）

• 程序启动实际的IO（例如，从fd读取）

相反，内核只需通知用户空间操作已经完成，应用程序可以处理接收到的数据，或者提交更多数据以发送。

边缘情况

由于这种高度集成，低级实现约束可能会变得明显，这些约束可能被具有更高开销的API所抽象化。

例如，在将 AIO 块提交到 USB 设备端点文件时，块应该对齐到页面边界，因为一些 USB 设备控制器没有读取/写入部分页面的能力。

在 Python 中，这意味着应该使用 mmap 来分配此类缓冲区，而不是使用任意的 bytearray。

实现细节出现的另一个地方是完成状态，res 和 res2。它们的意义取决于处理所使用文件描述符操作的模块，因此 python-libaio 在不假设它们的意义（而不是，例如，在负值上引发异常）的情况下传输这些值。

另一个地方是应用程序启动的关闭：取消 AIO 块时存在基本竞争条件（可能硬件触发的完成会先发生，或者可能是软件启动的取消）。在任何情况下，都会产生一个完成事件，应用程序可以检查哪个来源获胜。这一结果的后果是 AIO 上下文关闭可能需要时间：尽管请求取消不会阻塞，但软件应等待硬件返回缓冲区。

python 2 注意事项

在 Python 2.7 中，bytearray 的内存视图，尽管是可写的，但被 ctypes 拒绝。

>>> from ctypes import c_char
>>> a = bytearray(b'foo')
>>> c_char.from_buffer(a)
c_char('f')
>>> b = memoryview(a)
>>> b.readonly
False
>>> c_char.from_buffer(b)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: expected a writeable buffer object

这意味着在不复制内存的情况下，无法仅读取或写入大缓冲区开头的一小部分。

相同的代码与 Python 3.x 一起正常工作。

这被认为是 Python 2.7 的 ctypes 或 memoryview 错误，而不是 python-libaio 错误。

此外，memoryview 拒绝使用 mmap 对象

>>> import mmap
>>> a = mmap.mmap(-1, 16*1024)
>>> b = memoryview(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot make memory view because object does not have the buffer interface
>>>

…但 ctypes 对它很满意

>>> import ctypes
>>> c = (ctypes.c_char * len(a)).from_buffer(a)
>>>

…并且 memoryview 接受在 ctype 对象上构建

>>> d = memoryview(c)
>>>

…而且它真的工作了！

>>> a[0]
'\x00'
>>> c[0]
'\x00'
>>> d[0]
'\x00'
>>> d[0] = '\x01'
>>> c[0]
'\x01'
>>> a[0]
'\x01'
>>> a[0] = '\x02'
>>> c[0]
'\x02'
>>> d[0]
'\x02'

这被认为是 Python 2.7 的 memoryview 或 mmap 错误。