--- IO-AIO/AIO.pm 2011/09/27 01:43:03 1.210 +++ IO-AIO/AIO.pm 2012/03/27 18:54:45 1.219 @@ -170,7 +170,7 @@ use base 'Exporter'; BEGIN { - our $VERSION = '4.0'; + our $VERSION = '4.12'; our @AIO_REQ = qw(aio_sendfile aio_read aio_write aio_open aio_close aio_stat aio_lstat aio_unlink aio_rmdir aio_readdir aio_readdirx @@ -235,10 +235,10 @@ aio_readdirx $pathname, $flags, $callback->($entries, $flags) IO::AIO::READDIR_DENTS IO::AIO::READDIR_DIRS_FIRST IO::AIO::READDIR_STAT_ORDER IO::AIO::READDIR_FOUND_UNKNOWN + aio_scandir $pathname, $maxreq, $callback->($dirs, $nondirs) aio_load $pathname, $data, $callback->($status) aio_copy $srcpath, $dstpath, $callback->($status) aio_move $srcpath, $dstpath, $callback->($status) - aio_scandir $pathname, $maxreq, $callback->($dirs, $nondirs) aio_rmtree $pathname, $callback->($status) aio_sync $callback->($status) aio_syncfs $fh, $callback->($status) @@ -278,15 +278,20 @@ IO::AIO::munlock $scalar, $offset = 0, $length = undef IO::AIO::munlockall -=head2 AIO REQUEST FUNCTIONS +=head2 API NOTES All the C calls are more or less thin wrappers around the syscall with the same name (sans C). The arguments are similar or identical, and they all accept an additional (and optional) C<$callback> argument -which must be a code reference. This code reference will get called with -the syscall return code (e.g. most syscalls return C<-1> on error, unlike -perl, which usually delivers "false") as its sole argument after the given -syscall has been executed asynchronously. +which must be a code reference. This code reference will be called after +the syscall has been executed in an asynchronous fashion. The results +of the request will be passed as arguments to the callback (and, if an +error occured, in C<$!>) - for most requests the syscall return code (e.g. +most syscalls return C<-1> on error, unlike perl, which usually delivers +"false"). + +Some requests (such as C) pass the actual results and +communicate failures by passing C. All functions expecting a filehandle keep a copy of the filehandle internally until the request has finished. @@ -296,22 +301,26 @@ The pathnames you pass to these routines I be absolute. The reason for this is that at the time the request is being executed, the -current working directory could have changed. Alternatively, you can make -sure that you never change the current working directory anywhere in -the program and then use relative paths. Lastly, you can take advantage -of IO::AIOs working directory abstraction - see the description of the -C class later in this document. +current working directory could have changed. Alternatively, you can +make sure that you never change the current working directory anywhere +in the program and then use relative paths. You can also take advantage +of IO::AIOs working directory abstraction, that lets you specify paths +relative to some previously-opened "working directory object" - see the +description of the C class later in this document. To encode pathnames as octets, either make sure you either: a) always pass in filenames you got from outside (command line, readdir etc.) without -tinkering, b) are ASCII or ISO 8859-1, c) use the Encode module and encode -your pathnames to the locale (or other) encoding in effect in the user -environment, d) use Glib::filename_from_unicode on unicode filenames or e) -use something else to ensure your scalar has the correct contents. +tinkering, b) are in your native filesystem encoding, c) use the Encode +module and encode your pathnames to the locale (or other) encoding in +effect in the user environment, d) use Glib::filename_from_unicode on +unicode filenames or e) use something else to ensure your scalar has the +correct contents. This works, btw. independent of the internal UTF-8 bit, which IO::AIO handles correctly whether it is set or not. +=head2 AIO REQUEST FUNCTIONS + =over 4 =item $prev_pri = aioreq_pri [$pri] @@ -969,9 +978,11 @@ $maxreq = 4 if $maxreq <= 0; # get a wd object - aioreq_pri $pri; add $grp aio_wd $path, sub { + $_[0] + or return $grp->result (); + my $wd = [shift, "."]; # stat once @@ -1297,8 +1308,9 @@ Everywhere where a pathname is accepted by IO::AIO (e.g. in C or C), one can specify an array reference with an IO::AIO::WD -object and a pathname instead. If the pathname is absolute, the -IO::AIO::WD objetc is ignored, otherwise the pathname is resolved relative +object and a pathname instead (or the IO::AIO::WD object alone, which +gets interpreted as C<[$wd, "."]>). If the pathname is absolute, the +IO::AIO::WD object is ignored, otherwise the pathname is resolved relative to that IO::AIO::WD object. For example, to get a wd object for F and then stat F @@ -1316,8 +1328,16 @@ }; }; -This shows that creating an IO::AIO::WD object is itself a potentially -blocking operation, which is why it is done asynchronously. +That C is a request and not a normal function shows that creating +an IO::AIO::WD object is itself a potentially blocking operation, which is +why it is done asynchronously. + +To stat the directory obtained with C above, one could write +either of the following three request calls: + + aio_lstat "/etc" , sub { ... # pathname as normal string + aio_lstat [$wd, "."], sub { ... # "." relative to $wd (i.e. $wd itself) + aio_lstat $wd , sub { ... # shorthand for the previous As with normal pathnames, IO::AIO keeps a copy of the working directory object and the pathname string, so you could write the following without @@ -1507,8 +1527,8 @@ generator that generates requests if idle. The idea behind this is that, although you could just queue as many requests as you want in a group, this might starve other requests for a potentially long time. For example, -C might generate hundreds of thousands C requests, -delaying any later requests for a long time. +C might generate hundreds of thousands of C +requests, delaying any later requests for a long time. To avoid this, and allow incremental generation of requests, you can instead a group and set a feeder on it that generates those requests. The