[ViewVC] Diff of: cvs/IO-AIO/AIO.pm

Comparing IO-AIO/AIO.pm (file contents):
Revision 1.87 by root, Sun Oct 29 00:52:02 2006 UTC vs.
Revision 1.94 by root, Wed Nov 8 02:01:02 2006 UTC

 =head1 SYNOPSIS
  use IO::AIO;
  aio_open "/etc/passwd", O_RDONLY, 0, sub {
-    my ($fh) = @_;
+    my $fh = shift
+       or die "/etc/passwd: $!";
     ...
  };
  aio_unlink "/tmp/file", sub { };
 etc.), but can also be used to easily do operations in parallel that are
 normally done sequentially, e.g. stat'ing many files, which is much faster
 on a RAID volume or over NFS when you do a number of stat operations
 concurrently.
-While this works on all types of file descriptors (for example sockets),
+While most of this works on all types of file descriptors (for example
-using these functions on file descriptors that support nonblocking
+sockets), using these functions on file descriptors that support
-operation (again, sockets, pipes etc.) is very inefficient. Use an event
+nonblocking operation (again, sockets, pipes etc.) is very inefficient or
+might not work (aio_read fails on sockets/pipes/fifos). Use an event loop
-loop for that (such as the L<Event|Event> module): IO::AIO will naturally
+for that (such as the L<Event|Event> module): IO::AIO will naturally fit
-fit into such an event loop itself.
+into such an event loop itself.
 In this version, a number of threads are started that execute your
 requests and signal their completion. You don't need thread support
 in perl, and the threads created by this module will not be visible
 to perl. In the future, this module might make use of the native aio
               poll => 'r',
               cb => \&IO::AIO::poll_cb);
    # queue the request to open /etc/passwd
    aio_open "/etc/passwd", O_RDONLY, 0, sub {
-      my $fh = $_[0]
+      my $fh = shift
          or die "error while opening: $!";
       # stat'ing filehandles is generally non-blocking
       my $size = -s $fh;
 Request has reached the end of its lifetime and holds no resources anymore
 (except possibly for the Perl object, but its connection to the actual
 aio request is severed and calling its methods will either do nothing or
 result in a runtime error).
+=back
 =cut
 package IO::AIO;
 no warnings;
 use strict 'vars';
 use base 'Exporter';
 BEGIN {
-   our $VERSION = '2.1';
+   our $VERSION = '2.2';
    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_scandir aio_symlink
-                     aio_fsync aio_fdatasync aio_readahead aio_rename aio_link aio_move
+                     aio_readlink aio_fsync aio_fdatasync aio_readahead aio_rename aio_link
-                     aio_copy aio_group aio_nop aio_mknod);
+                     aio_move aio_copy aio_group aio_nop aio_mknod);
    our @EXPORT = (@AIO_REQ, qw(aioreq_pri aioreq_nice));
    our @EXPORT_OK = qw(poll_fileno poll_cb poll_wait flush
                        min_parallel max_parallel max_idle
                        nreqs nready npending nthreads
                        max_poll_time max_poll_reqs);
 =item aio_symlink $srcpath, $dstpath, $callback->($status)
 Asynchronously create a new symbolic link to the existing object at C<$srcpath> at
 the path C<$dstpath> and call the callback with the result code.
+=item aio_readlink $path, $callback->($link)
+Asynchronously read the symlink specified by C<$path> and pass it to
+the callback. If an error occurs, nothing or undef gets passed to the
+callback.
 =item aio_rename $srcpath, $dstpath, $callback->($status)
 Asynchronously rename the object at C<$srcpath> to C<$dstpath>, just as
 rename(2) and call the callback with the result code.
 that are being processed by C<IO::AIO::poll_cb> in one call, respectively
 the maximum amount of time (default C<0>, meaning infinity) spent in
 C<IO::AIO::poll_cb> to process requests (more correctly the mininum amount
 of time C<poll_cb> is allowed to use).
+Setting C<max_poll_time> to a non-zero value creates an overhead of one
+syscall per request processed, which is not normally a problem unless your
+callbacks are really really fast or your OS is really really slow (I am
+not mentioning Solaris here). Using C<max_poll_reqs> incurs no overhead.
 Setting these is useful if you want to ensure some level of
 interactiveness when perl is not fast enough to process all requests in
 time.
 For interactive programs, values such as C<0.01> to C<0.1> should be fine.
 Example: Install an Event watcher that automatically calls
-IO::AIO::poll_some with low priority, to ensure that other parts of the
+IO::AIO::poll_cb with low priority, to ensure that other parts of the
 program get the CPU sometimes even under high AIO load.
    # try not to spend much more than 0.1s in poll_cb
    IO::AIO::max_poll_time 0.1;
               poll => 'r', nice => 1,
               cb => &IO::AIO::poll_cb);
 =item IO::AIO::poll_wait
+If there are any outstanding requests and none of them in the result
-Wait till the result filehandle becomes ready for reading (simply does a
+phase, wait till the result filehandle becomes ready for reading (simply
-C<select> on the filehandle. This is useful if you want to synchronously
+does a C<select> on the filehandle. This is useful if you want to
-wait for some requests to finish).
+synchronously wait for some requests to finish).
 See C<nreqs> for an example.
 =item IO::AIO::poll
 Waits until some requests have been handled.
+Returns the number of requests processed, but is otherwise strictly
-Strictly equivalent to:
+equivalent to:
    IO::AIO::poll_wait, IO::AIO::poll_cb
-      if IO::AIO::nreqs;
 =item IO::AIO::flush
 Wait till all outstanding AIO requests have been handled.

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing IO-AIO/AIO.pm (file contents): Revision 1.87 by root, Sun Oct 29 00:52:02 2006 UTC vs. Revision 1.94 by root, Wed Nov 8 02:01:02 2006 UTC

Diff Legend

Comparing IO-AIO/AIO.pm (file contents):
Revision 1.87 by root, Sun Oct 29 00:52:02 2006 UTC vs.
Revision 1.94 by root, Wed Nov 8 02:01:02 2006 UTC