[ViewVC] Diff of: cvs/AnyEvent/lib/AnyEvent/Handle.pm

Comparing AnyEvent/lib/AnyEvent/Handle.pm (file contents):
Revision 1.67 by root, Fri Jun 6 15:33:10 2008 UTC vs.
Revision 1.76 by root, Sun Jul 27 03:28:36 2008 UTC

 AnyEvent::Handle - non-blocking I/O on file handles via AnyEvent
 =cut
-our $VERSION = 4.15;
+our $VERSION = 4.22;
 =head1 SYNOPSIS
    use AnyEvent;
    use AnyEvent::Handle;
 NOTE: The filehandle will be set to non-blocking (using
 AnyEvent::Util::fh_nonblocking).
 =item on_eof => $cb->($handle)
-Set the callback to be called when an end-of-file condition is detcted,
+Set the callback to be called when an end-of-file condition is detected,
 i.e. in the case of a socket, when the other side has closed the
 connection cleanly.
 While not mandatory, it is highly recommended to set an eof callback,
 otherwise you might end up with a closed socket while you are still
 This sets the callback that is called when the write buffer becomes empty
 (or when the callback is set and the buffer is empty already).
 To append to the write buffer, use the C<< ->push_write >> method.
+This callback is useful when you don't want to put all of your write data
+into the queue at once, for example, when you want to write the contents
+of some file to the socket you might not want to read the whole file into
+memory and push it into the queue, but instead only read more data from
+the file when the write queue becomes empty.
 =item timeout => $fractional_seconds
 If non-zero, then this enables an "inactivity" timeout: whenever this many
 seconds pass without a successful read or write on the underlying file
 handle, the C<on_timeout> callback will be invoked (and if that one is
 be configured to accept only so-and-so much data that it cannot act on
 (for example, when expecting a line, an attacker could send an unlimited
 amount of data without a callback ever being called as long as the line
 isn't finished).
+=item autocork => <boolean>
+When disabled (the default), then C<push_write> will try to immediately
+write the data to the handle if possible. This avoids having to register
+a write watcher and wait for the next event loop iteration, but can be
+inefficient if you write multiple small chunks (this disadvantage is
+usually avoided by your kernel's nagle algorithm, see C<low_delay>).
+When enabled, then writes will always be queued till the next event loop
+iteration. This is efficient when you do many small writes per iteration,
+but less efficient when you do a single write only.
+=item no_delay => <boolean>
+When doing small writes on sockets, your operating system kernel might
+wait a bit for more data before actually sending it out. This is called
+the Nagle algorithm, and usually it is beneficial.
+In some situations you want as low a delay as possible, which cna be
+accomplishd by setting this option to true.
+The default is your opertaing system's default behaviour, this option
+explicitly enables or disables it, if possible.
 =item read_size => <bytes>
 The default read block size (the amount of bytes this module will try to read
 during each (loop iteration). Default: C<8192>.
 You can also provide your own TLS connection object, but you have
 to make sure that you call either C<Net::SSLeay::set_connect_state>
 or C<Net::SSLeay::set_accept_state> on it before you pass it to
 AnyEvent::Handle.
-See the C<starttls> method if you need to start TLs negotiation later.
+See the C<starttls> method if you need to start TLS negotiation later.
 =item tls_ctx => $ssl_ctx
 Use the given Net::SSLeay::CTX object to create the new TLS connection
 (unless a connection object was specified directly). If this parameter is
    }
    $self->{_activity} = AnyEvent->now;
    $self->_timeout;
-   $self->on_drain (delete $self->{on_drain}) if $self->{on_drain};
+   $self->on_drain (delete $self->{on_drain}) if exists $self->{on_drain};
+   $self->no_delay (delete $self->{no_delay}) if exists $self->{no_delay};
    $self->start_read
       if $self->{on_read};
    $self
 =cut
 sub on_timeout {
    $_[0]{on_timeout} = $_[1];
+}
+=item $handle->autocork ($boolean)
+Enables or disables the current autocork behaviour (see C<autocork>
+constructor argument).
+=cut
+=item $handle->no_delay ($boolean)
+Enables or disables the C<no_delay> setting (see constructor argument of
+the same name for details).
+=cut
+sub no_delay {
+   $_[0]{no_delay} = $_[1];
+   eval {
+      local $SIG{__DIE__};
+      setsockopt $_[0]{fh}, &Socket::IPPROTO_TCP, &Socket::TCP_NODELAY, int $_[1];
+   };
 }
 #############################################################################
 =item $handle->timeout ($seconds)
             $self->_error ($!, 1);
          }
       };
       # try to write data immediately
-      $cb->();
+      $cb->() unless $self->{autocork};
       # if still data left in wbuf, we need to poll
       $self->{_ww} = AnyEvent->io (fh => $self->{fh}, poll => "w", cb => $cb)
          if length $self->{wbuf};
    };
 ways, the "simple" way, using only C<on_read> and the "complex" way, using
 a queue.
 In the simple case, you just install an C<on_read> callback and whenever
 new data arrives, it will be called. You can then remove some data (if
-enough is there) from the read buffer (C<< $handle->rbuf >>) if you want
+enough is there) from the read buffer (C<< $handle->rbuf >>). Or you cna
-or not.
+leave the data there if you want to accumulate more (e.g. when only a
+partial message has been received so far).
 In the more complex case, you want to queue multiple callbacks. In this
 case, AnyEvent::Handle will call the first queued callback each time new
 data arrives (also the first time it is queued) and removes it when it has
 done its job (see C<push_read>, below).
             # handle xml
          });
       });
    });
-Example 2: Implement a client for a protocol that replies either with
+Example 2: Implement a client for a protocol that replies either with "OK"
-"OK" and another line or "ERROR" for one request, and 64 bytes for the
+and another line or "ERROR" for the first request that is sent, and 64
-second request. Due tot he availability of a full queue, we can just
+bytes for the second request. Due to the availability of a queue, we can
-pipeline sending both requests and manipulate the queue as necessary in
+just pipeline sending both requests and manipulate the queue as necessary
-the callbacks:
+in the callbacks.
-   # request one
+When the first callback is called and sees an "OK" response, it will
+C<unshift> another line-read. This line-read will be queued I<before> the
+64-byte chunk callback.
+   # request one, returns either "OK + extra line" or "ERROR"
    $handle->push_write ("request 1\015\012");
    # we expect "ERROR" or "OK" as response, so push a line read
    $handle->push_read (line => sub {
       # if we got an "OK", we have to _prepend_ another line,
             ...
          });
       }
    });
-   # request two
+   # request two, simply returns 64 octets
    $handle->push_write ("request 2\015\012");
    # simply read 64 bytes, always
    $handle->push_read (chunk => 64, sub {
       my $response = $_[1];
 =cut
 register_read_type line => sub {
    my ($self, $cb, $eol) = @_;
-   $eol = qr|(\015?\012)| if @_ < 3;
+   if (@_ < 3) {
+      # this is more than twice as fast as the generic code below
+      sub {
+         $_[0]{rbuf} =~ s/^([^\015\012]*)(\015?\012)// or return;
+         $cb->($_[0], $1, $2);
+         1
+      }
+   } else {
-   $eol = quotemeta $eol unless ref $eol;
+      $eol = quotemeta $eol unless ref $eol;
-   $eol = qr|^(.*?)($eol)|s;
+      $eol = qr|^(.*?)($eol)|s;
-   sub {
+      sub {
-      $_[0]{rbuf} =~ s/$eol// or return;
+         $_[0]{rbuf} =~ s/$eol// or return;
-      $cb->($_[0], $1, $2);
+         $cb->($_[0], $1, $2);
+         1
-      1
+      }
    }
 };
 # compatibility with older API
 sub push_read_line {
 register_read_type packstring => sub {
    my ($self, $cb, $format) = @_;
    sub {
       # when we can use 5.10 we can use ".", but for 5.8 we use the re-pack method
-      defined (my $len = eval { unpack $format, $_[0]->{rbuf} })
+      defined (my $len = eval { unpack $format, $_[0]{rbuf} })
          or return;
       # remove prefix
-      substr $_[0]->{rbuf}, 0, (length pack $format, $len), "";
+      substr $_[0]{rbuf}, 0, (length pack $format, $len), "";
       # read rest
       $_[0]->unshift_read (chunk => $len, $cb);
       1
    require Storable;
    sub {
       # when we can use 5.10 we can use ".", but for 5.8 we use the re-pack method
-      defined (my $len = eval { unpack "w", $_[0]->{rbuf} })
+      defined (my $len = eval { unpack "w", $_[0]{rbuf} })
          or return;
       # remove prefix
-      substr $_[0]->{rbuf}, 0, (length pack "w", $len), "";
+      substr $_[0]{rbuf}, 0, (length pack "w", $len), "";
       # read rest
       $_[0]->unshift_read (chunk => $len, sub {
          if (my $ref = eval { Storable::thaw ($_[1]) }) {
             $cb->($_[0], $ref);
 =over 4
 =item * all constructor arguments become object members.
 At least initially, when you pass a C<tls>-argument to the constructor it
-will end up in C<< $handle->{tls} >>. Those members might be changes or
+will end up in C<< $handle->{tls} >>. Those members might be changed or
 mutated later on (for example C<tls> will hold the TLS connection object).
 =item * other object member names are prefixed with an C<_>.
 All object members not explicitly documented (internal use) are prefixed

Diff Legend

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

Comparing AnyEvent/lib/AnyEvent/Handle.pm (file contents): Revision 1.67 by root, Fri Jun 6 15:33:10 2008 UTC vs. Revision 1.76 by root, Sun Jul 27 03:28:36 2008 UTC

Diff Legend

Comparing AnyEvent/lib/AnyEvent/Handle.pm (file contents):
Revision 1.67 by root, Fri Jun 6 15:33:10 2008 UTC vs.
Revision 1.76 by root, Sun Jul 27 03:28:36 2008 UTC