AIO_WRITE(2)

πŸ“¦ version 15.1, in freebsd 14.5, freebsd 15.1

πŸ’œ AIO_WRITE(2) β€” the system calls manual page, bestie edition πŸ’œ

okay so you opened AIO_WRITE(2) from the System Calls Manual section and you're about to learn how to write to a file asynchronously, which is honestly main character energy. sit down, grab a strawberry πŸ“, let's go.


✨ NAME ✨

aio_write, aio_write2, aio_writev β€” asynchronous write to a file (REALTIME)


πŸŽ€ LIBRARY πŸŽ€

Standard C Library (libc, -lc) β€” the classic, the icon, the one you already link against πŸ’…


πŸ¦‹ SYNOPSIS πŸ¦‹

#include <aio.h>

int
aio_write(struct aiocb *iocb);

int
aio_write2(struct aiocb *iocb, int flags);

#include <sys/uio.h>

int
aio_writev(struct aiocb *iocb);

🌸 DESCRIPTION 🌸

So aio_write(), aio_write2(), and aio_writev() let your process write to the descriptor iocb->aio_fildes. and here's the vibe: the syscalls return immediately after the write request has been enqueued to the descriptor. the write may or may not have completed by the time the call comes back. it's giving "dropped it in the group chat and dipped" 😭

  • aio_write() writes iocb->aio_nbytes bytes from the buffer pointed to by iocb->aio_buf.
  • aio_writev() gathers the data from the iocb->aio_iovcnt buffers specified by the members of the iocb->aio_iov array.

if the request couldn't be enqueued β€” usually because the arguments were invalid β€” the call returns without having enqueued the request at all. rude but fair.

for aio_writev(), the iovec structure is defined in writev(2). iykyk πŸ’–

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

πŸ”₯ the flags argument (aio_write2 only)

aio_write2() takes the flags argument. if flags is passed as zero, the call behaves identically to aio_write(). you can specify the following flags by logical or:

  • AIO_OP2_FOFFSET β€” for non-O_APPEND file descriptors, the write occurs at the file descriptor offset, which is advanced by the operation the way write(2) does it. the iocb->aio_offset field is ignored πŸ™ˆ
  • AIO_OP2_VECTORED β€” similar to aio_writev(), the write buffers are specified by the aiocb->aio_iov array.

⭐ the iocb pointer glow-up

you can totally keep using that iocb pointer as an argument to aio_return() and aio_error() to figure out the return or error status of the enqueued operation while it's still in progress. multitasking icon πŸ’…

⚠️ but listen: if the request is successfully enqueued, the value of iocb->aio_offset can be modified during the request as context. so like… do not reference that value after the request is enqueued. it's not yours anymore, bestie.

the iocb->aio_sigevent structure can be used to request notification of the operation's completion, as described in aio(4). that's your little "it's done!" ping 🫢


🧚 RESTRICTIONS 🧚

  • 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. no take-backs, no freeing early.
  • the asynchronous I/O control buffer iocb should be zeroed before the system calls 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. literally nothing. crickets.

🌈 RETURN VALUES 🌈

aio_write() and aio_writev() return the value 0 if successful; otherwise the value -1 is returned and the global variable errno is set to indicate the error. classic.


πŸ’€ ERRORS πŸ’€

aio_write(), aio_write2(), and aio_writev() will fail if:

  • [EAGAIN] β€” the request was not queued because of system resource limitations.
  • [EFAULT] β€” part of aio_iov points outside the process's allocated address space.
  • [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 sneaky ones (sync or async detection)

these following conditions may be synchronously detected when the aio_write(), aio_write2(), or aio_writev() system call is made β€” or asynchronously, at any time thereafter. 😭

if they're detected at call time, the calls return -1 and set errno appropriately. otherwise you must call the aio_return() system call (which will return -1) and call aio_error() to determine the actual value that would have been returned in errno. two-step detective work, no shortcuts:

  • [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 it got enqueued but then things went sideways

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) β€” go read your siblings, they're all iconic ✨


🌺 STANDARDS 🌺

the aio_write() system call is expected to conform to the IEEE Std 1003.1 (β€œPOSIX.1”) standard. slay, portable.

the aio_write2() and aio_writev() system calls are FreeBSD extensions, and should not be used in portable code. adore them, but don't take them on tour 🧳


πŸŽ€ HISTORY πŸŽ€

  • aio_write() first appeared in FreeBSD 3.0.
  • aio_writev() first appeared in FreeBSD 13.0.
  • aio_write2() first appeared in FreeBSD 14.1.

a whole generational timeline, we love an evolution arc πŸ¦‹


πŸ’œ AUTHORS πŸ’œ

this manual page was written by Wes Peters <wes@softweyr.com>. thank you Wes, you ate πŸ‘‘


🫢 BUGS 🫢

invalid information in iocb->_aiocb_private may confuse the kernel. that's it. that's the bug. don't put nonsense in there and expect the kernel to be chill about it 😭


and that's the whole page bestie β€” no notes, no skips, every flag accounted for πŸ’…βœ¨

this page came to you from the Debian edition, dated March 27, 2025 β€” mwah, go write something asynchronously πŸŽ€πŸŒˆ

πŸ“¦ where this page comes from