.. contents::
Linux AIO API wrapper
This is about in-kernel, file-descriptor-based asynchronous I/O.
It has nothing to do with the ``asyncio`` standard module.
Linux AIO primer
----------------
When sending or expecting data, the typical issue a developer faces is knowing
when the operation will complete, so the program can carry on.
- read/write/recv/send: blocks until stuff happened
- same, on a non-blocking file descriptor: errors out instead of blocking,
developper has to implement retry somehow, and may end up wasting CPU time
just resubmitting the same operation over and over.
- select/poll/epoll: kernel tells the program when (re)submitting an operation
should not block (if developer is careful to not have competing IO sources)
AIO is the next level: the application expresses the intention that some IO
operation happens when the file descriptor accepts it *and* provides
corresponding buffer to the kernel.
Compared to select/poll/epoll, this avoids one round-trip to userland when the
operation becomes possible:
- kernel sends notification (ex: fd is readable)
- program initiates actual IO (ex: read from fd)
Instead, kernel only has to notify userland the operation is already completed,
and application may either process received data, or submit more data to send.
Edge cases
----------
Because of this high level of integration, low-level implementation
constraints which are abstracted by higher-overhead APIs may become apparent.
For example, when submitting AIO blocks to an USB gadget endpoint file, the
block should be aligned to page boundaries because some USB Device Controllers
do not have the ability to read/write partial pages.
In python, this means ``mmap`` should be used to allocate such buffer instead
of just any ``bytearray``.
Another place where implementation details appear is completion statuses,
``res`` and ``res2``. Their meaning depends on the module handling operations
on used file descriptor, so python-libaio transmits these values without
assuming their meaning (rather than, say, raise on negative values).
Yet another place is application-initiated closures: there is a fundamental
race-condition when cancelling an AIO block (maybe hardware-triggered
completion will happen first, or maybe software-initiated cancellation will).
In any case, a completion event will be produced and application may check
which origin won. A consequence of this is that AIO context closure may take
time: while requesting cancellation does not block, software should wait for
hardware to hand the buffers back.
python 2 Notes
--------------
In python 2.7, a memoryview of a bytearray, despite being writable, is rejected
by ctypes:
.. code:: python
>>> 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
This means that it is not possible to only read or write a few bytes at the
beginning of a large buffer without having to copy memory.
The same code works fine with python 3.x .
This is considered a python 2.7 ctypes or memoryview bug, and not a python-libaio bug.
Also, memoryview refuses to use an mmap object:
.. code:: python
>>> 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
>>>
...but ctypes is happy with it:
.. code:: python
>>> import ctypes
>>> c = (ctypes.c_char * len(a)).from_buffer(a)
>>>
...and memoryview accepts being constructed over ctype objects:
.. code:: python
>>> d = memoryview(c)
>>>
...and it really works !
.. code:: python
>>> 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'
This is considered a python 2.7 memoryview or mmap bug.
Raw data
{
"_id": null,
"home_page": "http://github.com/vpelletier/python-libaio",
"name": "libaio",
"maintainer": "",
"docs_url": null,
"requires_python": "",
"maintainer_email": "",
"keywords": "linux aio libaio",
"author": "Vincent Pelletier",
"author_email": "plr.vincent@gmail.com",
"download_url": "https://files.pythonhosted.org/packages/6b/63/ab54b879e055c333fe4b223cd43e2e27e101109c317c40a0b01e4d592fff/libaio-0.9.3.tar.gz",
"platform": "linux",
"description": ".. contents::\n\nLinux AIO API wrapper\n\nThis is about in-kernel, file-descriptor-based asynchronous I/O.\nIt has nothing to do with the ``asyncio`` standard module.\n\nLinux AIO primer\n----------------\n\nWhen sending or expecting data, the typical issue a developer faces is knowing\nwhen the operation will complete, so the program can carry on.\n\n- read/write/recv/send: blocks until stuff happened\n- same, on a non-blocking file descriptor: errors out instead of blocking,\n developper has to implement retry somehow, and may end up wasting CPU time\n just resubmitting the same operation over and over.\n- select/poll/epoll: kernel tells the program when (re)submitting an operation\n should not block (if developer is careful to not have competing IO sources)\n\nAIO is the next level: the application expresses the intention that some IO\noperation happens when the file descriptor accepts it *and* provides\ncorresponding buffer to the kernel.\nCompared to select/poll/epoll, this avoids one round-trip to userland when the\noperation becomes possible:\n\n- kernel sends notification (ex: fd is readable)\n- program initiates actual IO (ex: read from fd)\n\nInstead, kernel only has to notify userland the operation is already completed,\nand application may either process received data, or submit more data to send.\n\nEdge cases\n----------\n\nBecause of this high level of integration, low-level implementation\nconstraints which are abstracted by higher-overhead APIs may become apparent.\n\nFor example, when submitting AIO blocks to an USB gadget endpoint file, the\nblock should be aligned to page boundaries because some USB Device Controllers\ndo not have the ability to read/write partial pages.\n\nIn python, this means ``mmap`` should be used to allocate such buffer instead\nof just any ``bytearray``.\n\nAnother place where implementation details appear is completion statuses,\n``res`` and ``res2``. Their meaning depends on the module handling operations\non used file descriptor, so python-libaio transmits these values without\nassuming their meaning (rather than, say, raise on negative values).\n\nYet another place is application-initiated closures: there is a fundamental\nrace-condition when cancelling an AIO block (maybe hardware-triggered\ncompletion will happen first, or maybe software-initiated cancellation will).\nIn any case, a completion event will be produced and application may check\nwhich origin won. A consequence of this is that AIO context closure may take\ntime: while requesting cancellation does not block, software should wait for\nhardware to hand the buffers back.\n\npython 2 Notes\n--------------\n\nIn python 2.7, a memoryview of a bytearray, despite being writable, is rejected\nby ctypes:\n\n.. code:: python\n\n >>> from ctypes import c_char\n >>> a = bytearray(b'foo')\n >>> c_char.from_buffer(a)\n c_char('f')\n >>> b = memoryview(a)\n >>> b.readonly\n False\n >>> c_char.from_buffer(b)\n Traceback (most recent call last):\n File \"<stdin>\", line 1, in <module>\n TypeError: expected a writeable buffer object\n\nThis means that it is not possible to only read or write a few bytes at the\nbeginning of a large buffer without having to copy memory.\n\nThe same code works fine with python 3.x .\n\nThis is considered a python 2.7 ctypes or memoryview bug, and not a python-libaio bug.\n\nAlso, memoryview refuses to use an mmap object:\n\n.. code:: python\n\n >>> import mmap\n >>> a = mmap.mmap(-1, 16*1024)\n >>> b = memoryview(a)\n Traceback (most recent call last):\n File \"<stdin>\", line 1, in <module>\n TypeError: cannot make memory view because object does not have the buffer interface\n >>>\n\n...but ctypes is happy with it:\n\n.. code:: python\n\n >>> import ctypes\n >>> c = (ctypes.c_char * len(a)).from_buffer(a)\n >>>\n\n...and memoryview accepts being constructed over ctype objects:\n\n.. code:: python\n\n >>> d = memoryview(c)\n >>>\n\n...and it really works !\n\n.. code:: python\n\n >>> a[0]\n '\\x00'\n >>> c[0]\n '\\x00'\n >>> d[0]\n '\\x00'\n >>> d[0] = '\\x01'\n >>> c[0]\n '\\x01'\n >>> a[0]\n '\\x01'\n >>> a[0] = '\\x02'\n >>> c[0]\n '\\x02'\n >>> d[0]\n '\\x02'\n\nThis is considered a python 2.7 memoryview or mmap bug.\n",
"bugtrack_url": null,
"license": "LGPLv3+",
"summary": "Linux AIO API wrapper",
"version": "0.9.3",
"project_urls": {
"Homepage": "http://github.com/vpelletier/python-libaio"
},
"split_keywords": [
"linux",
"aio",
"libaio"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "6b63ab54b879e055c333fe4b223cd43e2e27e101109c317c40a0b01e4d592fff",
"md5": "f878fa4ea412f822af095e324788ccce",
"sha256": "910bccf66ac3a43959e3f1fb7871541b292d583f939fa24c6d67f4ad759e8f05"
},
"downloads": -1,
"filename": "libaio-0.9.3.tar.gz",
"has_sig": false,
"md5_digest": "f878fa4ea412f822af095e324788ccce",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 45380,
"upload_time": "2024-02-10T13:28:03",
"upload_time_iso_8601": "2024-02-10T13:28:03.582563Z",
"url": "https://files.pythonhosted.org/packages/6b/63/ab54b879e055c333fe4b223cd43e2e27e101109c317c40a0b01e4d592fff/libaio-0.9.3.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-02-10 13:28:03",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "vpelletier",
"github_project": "python-libaio",
"travis_ci": false,
"coveralls": false,
"github_actions": false,
"lcname": "libaio"
}
JSON
