python-trio
Consider supporting POSIX aio for disk I/O (mostly useful for FreeBSD)
Since trio seems to be growing support for the Linux specific io_uring including its async disk I/O features, what about POSIX aio support?
To might knowledge only FreeBSD (and possibly NetBSD) implements this in a useful, in kernel manner. Otherwise its usually user space threads managed by the systems C library, which is probably not much better than the current implementation.
If started on CFFI bindings at /wagnerflo/aiosix including an example how to use this with kqueue. Other operating systems would need to use other sigevent request completion notification mechanism (SIGEV_SIGNAL with a self-pipe or signalfd probably).
I've added a very rough benchmark script using asyncio mind you (that's what I'm much more proficient with). This kqueue + aio implementation is about 4-5 times faster than the naive run_in_executor version.
So there are two possible approaches here.
Option 1 is to write a thin wrapper that just gives the raw FreeBSD operations, probably as a third-party library rather than something built into trio itself. Trio tries to expose the necessary tools to hook into it's event loop; in this case:
https://trio.readthedocs.io/en/stable/reference-lowlevel.html#kqueue-specific-api https://github.com/python-trio/trio/blob/6b313de9edf3212c6e5ccfa69c68ef8a47bafc2f/trio/_core/_io_kqueue.py#L87-L132
So in theory, it should be possible to do this on Trio without messing around with custom loop subclasses or any hacks like that. In practice, I don't think anyone has ever used these APIs for real, so they probably have some annoying misdesigns that will become obvious as soon as you try to use them :-). If you do try this, it would be fantastic to get feedback so we can fix any awkwardness you run into.
Option 2 is to add a better file I/O abstraction to Trio, and then teach Trio to use this automatically on FreeBSD (and io_uring on Linux, etc.). This is more involved, because currently Trio's file I/O API delegates most of the work to Python's existing synchronous file I/O code, which is pretty complex (it handles caching, unicode, line endings, etc. etc.). So in order to do our own low-level file I/O, we'd have to throw all this out and write a whole new file I/O API from scratch.
I'm increasingly feeling like this is something we should do, given how good io_uring is looking. And if/when we do, then it would be cool to make Trio smart enough to automatically take advantage of FreeBSD's AIO when running on FreeBSD.
Option 1 is definitely a shorter path to get something working, but it requires users to write code against your FreeBSD-specific wrapper. Option 2 is more work, but it ends up with a generic file API that magically gets more efficient on FreeBSD.
I don't use FreeBSD myself, so I'm unlikely to implement this myself. But if you or someone else wants to take it on, go for it!
Option 1 is to write a thin wrapper that just gives the raw FreeBSD operations, probably as a third-party library rather than something built into trio itself. Trio tries to expose the necessary tools to hook into it's event loop; in this case: [...]
So in theory, it should be possible to do this on Trio without messing around with custom loop subclasses or any hacks like that. [...]
Yeah, I had a look at this and think the lowlevel API would easily suffice for that. I'll see if I can add a trio example to my repository some time soon.
Option 2 is to add a better file I/O abstraction to Trio, and then teach Trio to use this automatically on FreeBSD (and io_uring on Linux, etc.). This is more involved, because currently Trio's file I/O API delegates most of the work to Python's existing synchronous file I/O code, which is pretty complex (it handles caching, unicode, line endings, etc. etc.). So in order to do our own low-level file I/O, we'd have to throw all this out and write a whole new file I/O API from scratch.
I'm increasingly feeling like this is something we should do, given how good io_uring is looking. And if/when we do, then it would be cool to make Trio smart enough to automatically take advantage of FreeBSD's AIO when running on FreeBSD.
Reading #932 I was getting the impression that you were heading that way sooner or later anyways and it might be the right time to throw my FreeBSD support into the ring for when that time comes.
I don't use FreeBSD myself, so I'm unlikely to implement this myself. But if you or someone else wants to take it on, go for it!
Currently I'm too swamped with work to do an async rewrite of Python's io module, but I'm happy to get my POSIX aio bindings into a release ready state and add a few examples how using these with trio. Maybe an AsyncRawIOBase implementation or so...
Reading #932 I was getting the impression that you were heading that way sooner or later anyways
Yeah, I should probably write that down as its own issue. See #1960 :-)