|AIO(3)||Library Functions Manual||AIO(3)|
aio — asynchronous
The IEEE Std 1003.1-2001 (“POSIX.1”) standard defines an interface for asynchronous input and output. Although in NetBSD this is provided as part of the library “librt”, the implementation largely resides in the kernel.
The rationale can be roughly summarized with the following points.
aiointerface separates queuing and submitting I/O operations to the kernel, and receiving notifications of operation completion from the kernel.
aioavoids the need for (and the overhead of) extra worker threads sometimes used to perform asynchronous I/O.
The Asynchronous I/O Control Block is the basic operational unit
aio. This is required since an arbitrary
number of operations can be started at once, and because each operation can
be either input or output. This block is represented by the
aiocb structure, which is defined in the
<aio.h> header. The
following fields are available for user applications:
off_t aio_offset; void *aio_buf; size_t aio_nbytes; int aio_fildes; int aio_lio_opcode; int aio_reqprio; struct sigevent aio_sigevent;
The fields are:
lio_listio() function to initialize a list of I/O requests with a single call.
aiooperation. This is only available if
_POSIX_PRIORITY_SCHEDULINGare defined, and the associated file descriptor supports it.
The members aio_buf,
aio_fildes, and aio_nbytes are
conceptually similar to the parameters ‘buf’,
‘fildes’, and ‘nbytes’ used in the standard
write(2) functions. For
example, the caller can read aio_nbytes from a file
associated with the file descriptor aio_fildes into
the buffer aio_buf. All appropriate fields should be
initialized by the caller before
aio_write() is called.
Asynchronous I/O operations are not strictly sequential;
operations are carried out in arbitrary order and more than one operation
for one file descriptor can be started. The requested read or write
operation starts from the absolute position specified by
aio_offset, as if
lseek(2) would have been
SEEK_SET immediately prior to the
operation. The POSIX standard does not specify what happens after an
aio operation has been successfully completed.
Depending on the implementation, the actual file offset may or may not be
Asynchronous I/O operations are said to be complete when:
If an error condition is detected that prevents an operation from
being started, the request is not enqueued. In this case the read and write
aio_write(), return immediately, setting the global
errno to indicate the cause of the error.
After an operation has been successfully enqueued,
must be used to determine the status of the operation and to determine any
error conditions. This includes the conditions reported by the standard
fsync(2). The request remains
enqueued and consumes process and system resources until
aio_return() is called.
aio interface supports both polling
and notification models. The first can be implemented by simply repeatedly
aio_error() function to test the status
of an operation. Once the operation has completed,
aio_return() is used to free the
aiocb structure for re-use.
The notification model is implemented by using the aio_sigevent member of the Asynchronous I/O Control Block. The operational model and the used structure are described in sigevent(3).
aio_suspend() function can be used to
wait for the completion of one or more operations. It is possible to set a
timeout so that the process can continue the execution and take recovery
actions if the
aio operations do not complete as
aio_cancel() function can be used to
request cancellation of an asynchronous I/O operation. Note however that not
all of them can be canceled. The same aiocb used to
start the operation may be used as a handle for identification. It is also
possible to request cancellation of all operations pending for a file.
aio_fsync() function can be used to synchronize the
contents of permanent storage when multiple asynchronous I/O operations are
outstanding for the file or device. The synchronization operation includes
only those requests that have already been successfully enqueued.
The following functions comprise the API of the
|aio_cancel(3)||cancel an outstanding asynchronous I/O operation|
|aio_error(3)||retrieve error status of asynchronous I/O operation|
|aio_fsync(3)||asynchronous data synchronization of file|
|aio_read(3)||asynchronous read from a file|
|aio_return(3)||get return status of asynchronous I/O operation|
|aio_suspend(3)||suspend until operations or timeout complete|
|aio_write(3)||asynchronous write to a file|
|lio_listio(3)||list directed I/O|
Unfortunately, the POSIX asynchronous I/O implementations vary
slightly. Some implementations provide a slightly different API with
possible extensions. For instance, the FreeBSD
implementation uses a function
aio_waitcomplete()’ to wait for the
next completion of an
aio interface is expected to conform
to the IEEE Std 1003.1-2001
aio interface first appeared in
Few limitations can be mentioned:
|May 19, 2010||NetBSD-7.0.1|