is posix aio a good choice to do async file I/O on macOS? to avoid polling i want to specify a callback that is called when operation completes, is that possible at all?
aio on macOS
Posix aio should work on macOS. As to whether you should use it, that very much depends on the context. What sort of file I/O are you doing? And is this within some cross-platform library code? Or in code that’s already Mac specific?
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"
crossplatform to unix based systems is preferred, although if i have to use mac specific code i can stomach that.
ideally i want my internal api (based on aio or whatever else) to be exposed in the following form (pseudo code):
void myopen(file, callback)
void myread(ref, callback)
void mywrite(ref, callback)
void myclose(ref, callback)
void mydelete(file, callback)
void myrename(file, newName, callback)
... etc
this is for files only (not sockets).
the calls shall not block the current thread and callback shall be called eventually (ideally on the same thread) once the operation is completed.
in case of "myopen" i want it to asynchronously call the callback when the file is opened. for example if another part of my app or a different app opened the file with write permission and i call "myopen" on this file, i expect the callback to be called only after that other file reference is closed. on macOS open call may lead to "do you want the app to access that file" dialog, nanurally callback shall be called only after user has granted/or rejected that permission.
macOS doesn’t have any sort of async infrastructure for open, close, delete, and rename. These all go into the kernel and don’t come out until the operation is done. If you want to pretend that they’re async, you need to spin up a thread (or schedule the work on a queue). You have to be very careful to prevent thread explosion in that case (if your client asks to open 1000 files, you can’t spin up 1000 threads).
On the read and write front, I would look to Dispatch I/O. See the
dispatch_io_create
and
dispatch_read
man pages.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"
thank you,
good point about thread explosion, very easy to miss. last i tried i was able creating a few thousand, but i had to reduce the stack size and probably creating 10K threads is not a good idea anyway.
i am not rulling out dispatch_io... however, if i use aio_read / write can I use signals as a means to be notified about operation completion? what thread are those signals getting called on, if you know?
however, if i use
/aio_read
can I use signals as a means to be notified about operation completion?aio_write
I think so; AFAIK it’s part of the AIO spec.
Having said that, why would you want to do this? Signals are very hard to use correctly.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"
> why would you want to [use aio with signals]
i am enumerating available options. so far found these:
- blocking read in a thread plus a thread pool
- blocking read in a dispatch queue (similar to the above, apple onlyish)
- dispatch_read (uses blocking "read" internally on a thread, apple onlyish)
- PBReadAsync (obsolete, calls completion on a thread, apple only)
- aio_read plus signal (signals are hard to use)
- aio_read plus polling (poling feels bad)