coro::aio(3pm) [debian man page]
AIO(3pm) User Contributed Perl Documentation AIO(3pm) NAME
Coro::AIO - truly asynchronous file and directory I/O SYNOPSIS
use Coro::AIO; # can now use any of the aio requests your IO::AIO module supports. # read 1MB of /etc/passwd, without blocking other coroutines my $fh = aio_open "/etc/passwd", O_RDONLY, 0 or die "/etc/passwd: $!"; aio_read $fh, 0, 1_000_000, my $buf, 0 or die "aio_read: $!"; aio_close $fh; DESCRIPTION
This module is an AnyEvent user, you need to make sure that you use and run a supported event loop. This module implements a thin wrapper around IO::AIO. All of the functions that expect a callback are being wrapped by this module. The API is exactly the same as that of the corresponding IO::AIO routines, except that you have to specify all arguments, even the ones optional in IO::AIO, except the callback argument. Instead of calling a callback, the routines return the values normally passed to the callback. Everything else, including $! and perls stat cache, are set as expected after these functions return. You can mix calls to "IO::AIO" functions with calls to this module. You must not, however, call these routines from within IO::AIO callbacks, as this causes a deadlock. Start a coro inside the callback instead. This module also loads AnyEvent::AIO to integrate into the event loop in use, so please refer to its (and AnyEvent's) documentation on how it selects an appropriate event module. All other functions exported by default by IO::AIO (e.g. "aioreq_pri") will be exported by default by Coro::AIO, too. Functions that can be optionally imported from IO::AIO can be imported from Coro::AIO or can be called directly, e.g. "Coro::AIO::nreqs". You cannot specify priorities with "aioreq_pri" if your coroutine has a non-zero priority, as this module overwrites the request priority with the current coroutine priority in that case. For your convenience, here are the changed function signatures for most of the requests, for documentation of these functions please have a look at IO::AIO. Note that requests added by newer versions of IO::AIO will be automatically wrapped as well. @results = aio_wait $req This is not originally an IO::AIO request: what it does is to wait for $req to finish and return the results. This is most useful with "aio_group" requests. Is currently implemented by replacing the $req callback (and is very much like a wrapper around "$req->cb ()"). $fh = aio_open $pathname, $flags, $mode $status = aio_close $fh $retval = aio_read $fh,$offset,$length, $data,$dataoffset $retval = aio_write $fh,$offset,$length, $data,$dataoffset $retval = aio_sendfile $out_fh, $in_fh, $in_offset, $length $retval = aio_readahead $fh,$offset,$length $status = aio_stat $fh_or_path $status = aio_lstat $fh $status = aio_unlink $pathname $status = aio_rmdir $pathname $entries = aio_readdir $pathname ($dirs, $nondirs) = aio_scandir $path, $maxreq $status = aio_fsync $fh $status = aio_fdatasync $fh ... = aio_xxx ... Any additional aio requests follow the same scheme: same parameters except you must not specify a callback but instead get the callback arguments as return values. SEE ALSO
Coro::Socket and Coro::Handle for non-blocking socket operation. AUTHOR
Marc Lehmann <schmorp@schmorp.de> http://home.schmorp.de/ perl v5.14.2 2012-04-13 AIO(3pm)
Check Out this Related Man Page
aio_proc_thread_pct(5) File Formats Manual aio_proc_thread_pct(5) NAME
aio_proc_thread_pct - percentage of all process threads allowed in AIO pool VALUES
Failsafe Default Allowed values Recommended values DESCRIPTION
The implementation of POSIX AIO on HP-UX uses kernel threads to perform I/Os to filesystems that do not directly support true asynchronous I/O. (This distinction is transparent to the user.) The kernel threads are organized into worker-thread pools (called AIO thread pools) created on a per-process basis. Since a thread pool mechanism for I/Os introduces a variety of trade-offs concerning utilization of CPU time vs. I/O resources, four dynamic tunables are available to customize the behavior of this thread pool: aio_proc_threads(5), aio_proc_thread_pct(5), aio_req_per_thread(5), and aio_monitor_run_sec(5). Please see individual manpages for details on each of these tunables. The tunable specifies, on a per-process basis, the percentage of threads that can be used by the POSIX AIO system as kernel threads for issuing I/Os. The percentage is taken as a percentage of which is the upper bound on the number of threads a process may have. This tunable interacts with in the following way: the maximum number of threads used for AIO will be the smaller of the two values defined by the two tunables; i.e.: This allows the number of AIO threads to vary dynamically with but to always be bound by an absolute limit of Who Is Expected to Change This Tunable? System administrators that run applications requiring heavy usage of POSIX AIO to filesystems. Restrictions on Changing This tunables is dynamic. Changes to to this tunable take effect immediately for new processes started after the change. They also impact existing processes, but the speed with which the changes propagate to running processes is determined by the tunable When Should the Value of This Tunable Be Raised? should be raised for applications that do not use very many threads for their own work, but desire high performance from the POSIX AIO sub- system. What Are the Side Effects of Raising the Value of This Tunable? Some applications that use POSIX AIO but also require a large number of threads may find that they are unable to create new threads, because the POSIX AIO thread pool ends up using too many of a process' allowable threads. In addition, using a larger number of kernel threads might lead to increased CPU utilization. When Should the Value of This Tunable Be Lowered? should be lowered when POSIX AIO performance is acceptable but applications using POSIX AIO are seeing errors when trying to create new threads for other work. What Are the Side Effects of Lowering the Value of This Tunable? By ultimately reducing the number of threads available to handle POSIX AIO requests, overall I/O throughput of the POSIX AIO subsystem could be reduced. What Other Tunables Should Be Changed at the Same Time as This One? interacts with this tunable by setting a strict limit on the number of threads that can be used for POSIX AIO. This allows a hard limit to be imposed, regardless of what value happens to take. defines the desired relationship between the number of POSIX AIO kernel threads and the number of I/Os to be serviced. defines how often (in seconds) the AIO thread mechanism will monitor itself for adherence to the constraints defined by the tunables above. WARNINGS
All HP-UX kernel tunable parameters are release specific. This parameter may be removed or have its meaning changed in future releases of HP-UX. Installation of optional kernel software, from HP or other vendors, may cause changes to tunable parameter values. After installation, some tunable parameters may no longer be at the default or recommended values. For information about the effects of installation on tun- able values, consult the documentation for the kernel software being installed. For information about optional kernel software that was factory installed on your system, see at AUTHOR
was developed by HP. SEE ALSO
kctune(1M), sam(1M), gettune(2), settune(2), aio_proc_threads(5), aio_req_per_thread(5), aio_monitor_run_sec(5). Tunable Kernel Parameters aio_proc_thread_pct(5)