AIO_WRITE(2)

✨ AIO_WRITE(2) ✨ — the async write girlies' manual 💅

okay so bestie, this is the System Calls Manual page for aio_write, no cap. it's a realtime thing. it's giving concurrency. let's get into it 🦋

---

🌸 NAME 🌸

aio_write — asynchronous write to a file (REALTIME)

literally it writes to a file but it does NOT wait around for it. main character energy.

---

📚 LIBRARY 📚

Standard C Library (libc, -lc)

---

🎀 SYNOPSIS 🎀

#include <aio.h>

int
aio_write(struct aiocb *iocb);

---

💖 DESCRIPTION 💖

okay so here's the tea. the aio_write() system call lets the calling process write iocb->aio_nbytes from the buffer pointed to by iocb->aio_buf over to the descriptor iocb->aio_fildes. and the way it does it?? the call returns immediately after the write request has been enqueued to the descriptor. so the write may or may not have actually completed by the time the call returns — she's mysterious like that ✨. if the request could not be enqueued, generally because of invalid arguments, the call just returns without having enqueued the request. nothing happened, move on 💀.

if O_APPEND is set for iocb->aio_fildes, then aio_write() operations append to the file in the same order as the calls were made (queued girlies stay in line, periodt). if O_APPEND is not set for the file descriptor, the write operation will occur at the absolute position from the beginning of the file plus iocb->aio_offset.

if _POSIX_PRIORITIZED_IO is defined, and the descriptor supports it, then the enqueued operation is submitted at a priority equal to that of the calling process minus iocb->aio_reqprio. yes, minus. math. 🙈

the iocb pointer may be subsequently used as an argument to aio_return() and aio_error() so you can figure out the return or error status for the enqueued operation while it's still in progress. multitasking icon behavior.

if the request is successfully enqueued, the value of iocb->aio_offset can be modified during the request as context, so this value must not be referenced after the request is enqueued. do not. it's not yours anymore bestie, let it go 😭.

the iocb->aio_sigevent structure can be used to request notification of the operation's completion, as described in aio(4). she'll text you when she's done 🫶.

---

🚧 RESTRICTIONS 🚧

okay this is the part where we have to be responsible 💜:

• The Asynchronous I/O Control Block structure pointed to by iocb and the buffer that the iocb->aio_buf member of that structure references must remain valid until the operation has completed. like, do not free her. do not move her. she is busy.
• The asynchronous I/O control buffer iocb should be zeroed before the aio_write() system call, to avoid passing bogus context information to the kernel. bogus context is NOT the vibe.
• Modifications of the Asynchronous I/O Control Block structure or the buffer contents are not allowed while the request is queued. hands off 🙅‍♀️.
• If the file offset in iocb->aio_offset is past the offset maximum for iocb->aio_fildes, no I/O will occur. nothing. zero. the void 💀.

---

🌈 RETURN VALUES 🌈

The aio_write() function returns the value 0 if successful; otherwise the value -1 is returned and the global variable errno is set to indicate the error.

that's it. 0 = slay, -1 = check errno, we move.

---

🔥 ERRORS 🔥

The aio_write() system call will fail if:

• [EAGAIN] — The request was not queued because of system resource limitations. (the system said "no room bestie" 😔)
• [EINVAL] — The asynchronous notification method in iocb->aio_sigevent.sigev_notify is invalid or not supported.
• [EOPNOTSUPP] — Asynchronous write operations on the file descriptor iocb->aio_fildes are unsafe and unsafe asynchronous I/O operations are disabled.

The following conditions may be synchronously detected when the aio_write() system call is made, or asynchronously, at any time thereafter. If they are detected at call time, aio_write() returns -1 and sets errno appropriately; otherwise the aio_return() system call must be called, and will return -1, and aio_error() must be called to determine the actual value that would have been returned in errno. (yes you have to go ask the other two functions, it's a whole group chat investigation 🔍)

• [EBADF] — The iocb->aio_fildes argument is invalid, or is not opened for writing.
• [EINVAL] — The offset iocb->aio_offset is not valid, the priority specified by iocb->aio_reqprio is not a valid priority, or the number of bytes specified by iocb->aio_nbytes is not valid.

If the request is successfully enqueued, but subsequently canceled or an error occurs, the value returned by the aio_return() system call is per the write(2) system call, and the value returned by the aio_error() system call is either one of the error returns from the write(2) system call, or one of:

• [EBADF] — The iocb->aio_fildes argument is invalid for writing.
• [ECANCELED] — The request was explicitly canceled via a call to aio_cancel().
• [EINVAL] — The offset iocb->aio_offset would be invalid.

---

👀 SEE ALSO 👀

aio_cancel(2), aio_error(2), aio_return(2), aio_suspend(2), aio_waitcomplete(2), sigevent(3), siginfo(3), aio(4)

the whole friend group honestly 🫶

---

⭐ STANDARDS ⭐

The aio_write() system call is expected to conform to the IEEE Std 1003.1 (“POSIX.1”) standard. certified. official. iconic 👑.

---

🕰️ HISTORY 🕰️

The aio_write() system call first appeared in FreeBSD 3.0. vintage but make it async ✨.

---

🖊️ AUTHORS 🖊️

This manual page was written by Wes Peters <wes@softweyr.com>. thank you wes, king behavior 💜.

---

🐛 BUGS 🐛

Invalid information in iocb->_aiocb_private may confuse the kernel. the kernel gets confused. we've all been there 🙈.

---

reminder bestie: zero the iocb, keep the buffer alive, and never peek at iocb->aio_offset after enqueue. that's the whole plot 💅

---

and that's a wrap on the Debian version of this page, dated August 19, 2016 — AIO_WRITE(2), signing off, mwah 💋 🌸🦋🎀