HP-UX Reference (11i v3 07/02) - 5 Miscellaneous Topics (vol 9)

a
aio(5) aio(5)
notification model is implemented by designating a
sigevent in the aiocb used to start the operation.
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 opera-
tion. The aiocb used to start the operation may be used as a handle to identify it for cancellation. Can-
cellation of all operations pending for a file may also be requested. Not all asynchronous I/O operations 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 con-
trol 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 addi-
tion to the system-wide limit, there is a per-process limit. It is controlled using the argument
RLIMIT_AIO_OPS to the getrlimit() and setrlimit() system calls. Even though an asynchro-
nous I/O operation has completed, it still remains enqueued until aio_return() is called for that opera-
tion.
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
40 Hewlett-Packard Company − 3 − HP-UX 11i Version 3: February 2007