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

Comparing IO-AIO/AIO.pm (file contents):
Revision 1.86 by root, Sat Oct 28 23:32:29 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);
    XSLoader::load ("IO::AIO", $VERSION);
 }
 =head1 FUNCTIONS
-=head2 AIO FUNCTIONS
+=head2 AIO REQUEST FUNCTIONS
 All the C<aio_*> calls are more or less thin wrappers around the syscall
 with the same name (sans C<aio_>). 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
 syscall has been executed asynchronously.
 All functions expecting a filehandle keep a copy of the filehandle
 internally until the request has finished.
-All requests return objects of type L<IO::AIO::REQ> that allow further
+All functions return request objects of type L<IO::AIO::REQ> that allow
-manipulation of those requests while they are in-flight.
+further manipulation of those requests while they are in-flight.
 The pathnames you pass to these routines I<must> be absolute and
-encoded in byte form. The reason for the former is that at the time the
+encoded as octets. The reason for the former 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.
+current working directory anywhere in the program and then use relative
+paths.
-To encode pathnames to byte form, either make sure you either: a)
+To encode pathnames as octets, either make sure you either: a) always pass
-always pass in filenames you got from outside (command line, readdir
+in filenames you got from outside (command line, readdir etc.) without
-etc.), b) are ASCII or ISO 8859-1, c) use the Encode module and encode
+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.
+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 wether it is set or not.
 =over 4
 =item $prev_pri = aioreq_pri [$pri]
    };
 =item aioreq_nice $pri_adjust
 Similar to C<aioreq_pri>, but subtracts the given value from the current
-priority, so effects are cumulative.
+priority, so the effect is cumulative.
 =item aio_open $pathname, $flags, $mode, $callback->($fh)
 Asynchronously open or create a file and call the callback with a newly
 created filehandle for the file.
 =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.86 by root, Sat Oct 28 23:32:29 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.86 by root, Sat Oct 28 23:32:29 2006 UTC vs.
Revision 1.94 by root, Wed Nov 8 02:01:02 2006 UTC