aio.5 (2010 09)

a
aio(5) aio(5)
The specified notification, if any, is then performed when the operation completes.
The
aio_suspend()
function allows the application to wait for completion of one or more asynchronous
I/O operations. A timeout may be set so that the process can again execute and take appropriate recovery
actions if the expected operations do not complete as expected. If the
aio_suspend()
references multi-
ple operations, return is made when any one of the operations completes.
Retrieving Errors
Once an asynchronous I/O operation has been started, its status can be tested with the
aio_error()
and aio_return() functions, which return the current status of a referenced
aiocb.Forapolling
implementation, the
aio_error() function is used to check the status until a completion status is seen;
then
aio_return() is used to free the aiocb
for re-use.
For a notification implementation, status of the completed I/O can be determined and the
aiocb freed
with a single call to
aio_return().
The errors reported by
aio_error() and aio_return()
include all of the errors normally reported
by
read() and write() plus errors unique to asynchronous I/O processing. After an asynchronous I/O
operation is started but before an error is detected or the operation completes successfully,
aio_error() will return EINPROGRESS.
Cancellation
The
aio_cancel() function allows an application to request cancellation of an asynchronous I/O
operation. The aiocb used to start the operation may be used as a handle to identify it for cancellation.
Cancellation of all operations pending for a file may also be requested. Not all asynchronous I/O opera-
tions can be canceled.
Synchronizing Permanent Storage
The
aio_fsync() function supports synchronizing the contents of permanent storage when multiple
asynchronous I/O operations are outstanding for the file or device. Only those requests already enqueued
for the designated file at the time of the function call are included in the synchronization operation.
File Offsets
Asynchronous I/O operations are not inherently sequential. Each operation must specify an offset, and
the file offset is never updated as a result of an asynchronous I/O operation.
Setting the O_APPEND flag on a file limits the value of asynchronous I/O to that file. When
O_APPEND is
set, operations on the file will be handled serially with the ending file length after one request providing
the starting offset for the next. While there may be some advantage to allowing the system to queue
requests, care should be taken not to exhaust system or process resources by enqueuing a large number of
requests that must be processed serially.
System Limitations and Restrictions
The operation of the POSIX Asynchronous I/O interfaces is subject to certain system limitations and res-
trictions.
Since each enqueued asynchronous I/O operation requires allocation of system memory for its internal
control structure, the number of simultaneously enqueued asynchronous I/O operations that the system
can have pending is limited. The maximum number of asynchronous I/O operations that all active
processes on the system may have enqueued concurrently is tunable. The current maximum value can be
obtained using the
sysconf() call with the argument _SC_AIO_MAX. The default maximum value is
2048. In addition to the system-wide limit, there is a per-process limit. It is controlled using the argu-
ment RLIMIT_AIO_OPS to the getrlimit() and setrlimit() system calls. Even though an asyn-
chronous I/O operation has completed, it still remains enqueued until aio_return() is called for that
operation.
Asynchronous I/O operations which use the request and call back mechanism rather than the threads
mechanism for I/O, are subject to a system-wide limit on the amount of physical memory that can be
locked during asynchronous I/O transfers. This system-wide maximum number of bytes of memory that
can be locked simultaneously for aio requests is tunable. This can be set as a percentage of the physical
memory available on the system. By default, it is set to 10% of the physical memory. In addition to the
system-wide limit, there is a per-process limit which is controlled using the argument
RLIMIT_AIO_MEM
to the getrlimit() and setrlimit() system calls. Further, the amount of memory that can be
locked at a time for any reason, not just for asynchronous I/O, is controlled by the system-wide limit
lockable_mem. Other system activity, including explicit memory locking with plock() and/or
mlock() interfaces may affect the amount of lockable memory at any given time.
HP-UX 11i Version 3: September 2010 − 3 − Hewlett-Packard Company 3