Provided by: libio-async-perl_0.61-1_all bug

NAME

       "IO::Async::Stream" - event callbacks and write bufering for a stream filehandle

SYNOPSIS

        use IO::Async::Stream;

        use IO::Async::Loop;
        my $loop = IO::Async::Loop->new;

        my $stream = IO::Async::Stream->new(
           read_handle  => \*STDIN,
           write_handle => \*STDOUT,

           on_read => sub {
              my ( $self, $buffref, $eof ) = @_;

              while( $$buffref =~ s/^(.*\n)// ) {
                 print "Received a line $1";
              }

              if( $eof ) {
                 print "EOF; last partial line is $$buffref\n";
              }

              return 0;
           }
        );

        $loop->add( $stream );

        $stream->write( "An initial line here\n" );

DESCRIPTION

       This subclass of IO::Async::Handle contains a filehandle that represents a byte-stream. It
       provides buffering for both incoming and outgoing data. It invokes the "on_read" handler
       when new data is read from the filehandle. Data may be written to the filehandle by
       calling the "write" method.

       For implementing real network protocols that are based on messages sent over a byte-stream
       (such as a TCP socket), it may be more appropriate to use a subclass of
       IO::Async::Protocol::Stream.

EVENTS

       The following events are invoked, either using subclass methods or CODE references in
       parameters:

   $ret = on_read \$buffer, $eof
       Invoked when more data is available in the internal receiving buffer.

       The first argument is a reference to a plain perl string. The code should inspect and
       remove any data it likes, but is not required to remove all, or indeed any of the data.
       Any data remaining in the buffer will be preserved for the next call, the next time more
       data is received from the handle.

       In this way, it is easy to implement code that reads records of some form when completed,
       but ignores partially-received records, until all the data is present. If the handler is
       confident no more useful data remains, it should return 0. If not, it should return 1, and
       the handler will be called again. This makes it easy to implement code that handles
       multiple incoming records at the same time. See the examples at the end of this
       documentation for more detail.

       The second argument is a scalar indicating whether the stream has reported an end-of-file
       (EOF) condition. A reference to the buffer is passed to the handler in the usual way, so
       it may inspect data contained in it. Once the handler returns a false value, it will not
       be called again, as the handle is now at EOF and no more data can arrive.

       The "on_read" code may also dynamically replace itself with a new callback by returning a
       CODE reference instead of 0 or 1. The original callback or method that the object first
       started with may be restored by returning "undef". Whenever the callback is changed in
       this way, the new code is called again; even if the read buffer is currently empty. See
       the examples at the end of this documentation for more detail.

       The "push_on_read" method can be used to insert new, temporary handlers that take
       precedence over the global "on_read" handler. This event is only used if there are no
       further pending handlers created by "push_on_read".

   on_read_eof
       Optional. Invoked when the read handle indicates an end-of-file (EOF) condition. If there
       is any data in the buffer still to be processed, the "on_read" event will be invoked
       first, before this one.

   on_write_eof
       Optional. Invoked when the write handle indicates an end-of-file (EOF) condition. Note
       that this condition can only be detected after a "write" syscall returns the "EPIPE"
       error. If there is no data pending to be written then it will not be detected yet.

   on_read_error $errno
       Optional. Invoked when the "sysread" method on the read handle fails.

   on_write_error $errno
       Optional. Invoked when the "syswrite" method on the write handle fails.

       The "on_read_error" and "on_write_error" handlers are passed the value of $! at the time
       the error occured. (The $! variable itself, by its nature, may have changed from the
       original error by the time this handler runs so it should always use the value passed in).

       If an error occurs when the corresponding error callback is not supplied, and there is not
       a handler for it, then the "close" method is called instead.

   on_read_high_watermark $length
   on_read_low_watermark $length
       Optional. Invoked when the read buffer grows larger than the high watermark or smaller
       than the low watermark respectively. These are edge-triggered events; they will only be
       triggered once per crossing, not continuously while the buffer remains above or below the
       given limit.

       If these event handlers are not defined, the default behaviour is to disable read-ready
       notifications if the read buffer grows larger than the high watermark (so as to avoid it
       growing arbitrarily if nothing is consuming it), and re-enable notifications again once
       something has read enough to cause it to drop. If these events are overridden, the
       overriding code will have to perform this behaviour if required, by using

        $self->want_readready_for_read(...)

   on_outgoing_empty
       Optional. Invoked when the writing data buffer becomes empty.

   on_writeable_start
   on_writeable_stop
       Optional. These two events inform when the filehandle becomes writeable, and when it stops
       being writeable. "on_writeable_start" is invoked by the "on_write_ready" event if
       previously it was known to be not writeable.  "on_writeable_stop" is invoked after a
       "syswrite" operation fails with "EAGAIN" or "EWOULDBLOCK". These two events track the
       writeability state, and ensure that only state change cause events to be invoked. A stream
       starts off being presumed writeable, so the first of these events to be observed will be
       "on_writeable_stop".

PARAMETERS

       The following named parameters may be passed to "new" or "configure":

       read_handle => IO
               The IO handle to read from. Must implement "fileno" and "sysread" methods.

       write_handle => IO
               The IO handle to write to. Must implement "fileno" and "syswrite" methods.

       handle => IO
               Shortcut to specifying the same IO handle for both of the above.

       on_read => CODE
       on_read_error => CODE
       on_outgoing_empty => CODE
       on_write_error => CODE
       on_writeable_start => CODE
       on_writeable_stop => CODE
               CODE references for event handlers.

       autoflush => BOOL
               Optional. If true, the "write" method will attempt to write data to the operating
               system immediately, without waiting for the loop to indicate the filehandle is
               write-ready. This is useful, for example, on streams that should contain up-to-
               date logging or console information.

               It currently defaults to false for any file handle, but future versions of
               "IO::Async" may enable this by default on STDOUT and STDERR.

       read_len => INT
               Optional. Sets the buffer size for "read" calls. Defaults to 8 KiBytes.

       read_all => BOOL
               Optional. If true, attempt to read as much data from the kernel as possible when
               the handle becomes readable. By default this is turned off, meaning at most one
               fixed-size buffer is read. If there is still more data in the kernel's buffer, the
               handle will still be readable, and will be read from again.

               This behaviour allows multiple streams and sockets to be multiplexed
               simultaneously, meaning that a large bulk transfer on one cannot starve other
               filehandles of processing time. Turning this option on may improve bulk data
               transfer rate, at the risk of delaying or stalling processing on other
               filehandles.

       write_len => INT
               Optional. Sets the buffer size for "write" calls. Defaults to 8 KiBytes.

       write_all => BOOL
               Optional. Analogous to the "read_all" option, but for writing. When "autoflush" is
               enabled, this option only affects deferred writing if the initial attempt failed
               due to buffer space.

       read_high_watermark => INT
       read_low_watermark => INT
               Optional. If defined, gives a way to implement flow control or other behaviours
               that depend on the size of Stream's read buffer.

               If after more data is read from the underlying filehandle the read buffer is now
               larger than the high watermark, the "on_read_high_watermark" event is triggered
               (which, by default, will disable read-ready notifications and pause reading from
               the filehandle).

               If after data is consumed by an "on_read" handler the read buffer is now smaller
               than the low watermark, the "on_read_low_watermark" event is triggered (which, by
               default, will re-enable read-ready notifications and resume reading from the
               filehandle). For to be possible, the read handler would have to be one added by
               the "push_on_read" method or one of the Future-returning "read_*" methods.

               By default these options are not defined, so this behaviour will not happen.
               "read_low_watermark" may not be set to a larger value than "read_high_watermark",
               but it may be set to a smaller value, creating a hysteresis region. If either
               option is defined then both must be.

               If these options are used with the default event handlers, be careful not to cause
               deadlocks by having a high watermark sufficiently low that a single "on_read"
               invocation might not consider it finished yet.

       reader => STRING|CODE
       writer => STRING|CODE
               Optional. If defined, gives the name of a method or a CODE reference to use to
               implement the actual reading from or writing to the filehandle. These will be
               invoked as

                $stream->reader( $read_handle, $buffer, $len )
                $stream->writer( $write_handle, $buffer, $len )

               Each is expected to modify the passed buffer; "reader" by appending to it,
               "writer" by removing a prefix from it. Each is expected to return a true value on
               success, zero on EOF, or "undef" with $! set for errors. If not provided, they
               will be substituted by implenentations using "sysread" and "syswrite" on the
               underlying handle, respectively.

       close_on_read_eof => BOOL
               Optional. Usually true, but if set to a false value then the stream will not be
               "close"d when an EOF condition occurs on read. This is normally not useful as at
               that point the underlying stream filehandle is no longer useable, but it may be
               useful for reading regular files, or interacting with TTY devices.

       encoding => STRING
               If supplied, sets the name of encoding of the underlying stream. If an encoding is
               set, then the "write" method will expect to receive Unicode strings and encodes
               them into bytes, and incoming bytes will be decoded into Unicode strings for the
               "on_read" event.

               If an encoding is not supplied then "write" and "on_read" will work in byte
               strings.

               IMPORTANT NOTE: in order to handle reads of UTF-8 content or other multibyte
               encodings, the code implementing the "on_read" event uses a feature of Encode; the
               "STOP_AT_PARTIAL" flag. While this flag has existed for a while and is used by the
               ":encoding" PerlIO layer itself for similar purposes, the flag is not officially
               documented by the "Encode" module. In principle this undocumented feature could be
               subject to change, in practice I believe it to be reasonably stable.

               This note applies only to the "on_read" event; data written using the "write"
               method does not rely on any undocumented features of "Encode".

       If a read handle is given, it is required that either an "on_read" callback reference is
       configured, or that the object provides an "on_read" method. It is optional whether either
       is true for "on_outgoing_empty"; if neither is supplied then no action will be taken when
       the writing buffer becomes empty.

       An "on_read" handler may be supplied even if no read handle is yet given, to be used when
       a read handle is eventually provided by the "set_handles" method.

       This condition is checked at the time the object is added to a Loop; it is allowed to
       create a "IO::Async::Stream" object with a read handle but without a "on_read" handler,
       provided that one is later given using "configure" before the stream is added to its
       containing Loop, either directly or by being a child of another Notifier already in a
       Loop, or added to one.

METHODS

   $stream->want_readready_for_read( $set )
   $stream->want_readready_for_write( $set )
       Mutators for the "want_readready" property on IO::Async::Handle, which control whether the
       "read" or "write" behaviour should be continued once the filehandle becomes ready for
       read.

       Normally, "want_readready_for_read" is always true (though the read watermark behaviour
       can modify it), and "want_readready_for_write" is not used.  However, if a custom "writer"
       function is provided, it may find this useful for being invoked again if it cannot proceed
       with a write operation until the filehandle becomes readable (such as during transport
       negotiation or SSL key management, for example).

   $stream->want_writeready_for_write( $set )
   $stream->want_writeready_for_read( $set )
       Mutators for the "want_writeready" property on IO::Async::Handle, which control whether
       the "write" or "read" behaviour should be continued once the filehandle becomes ready for
       write.

       Normally, "want_writeready_for_write" is managed by the "write" method and associated
       flushing, and "want_writeready_for_read" is not used. However, if a custom "reader"
       function is provided, it may find this useful for being invoked again if it cannot proceed
       with a read operation until the filehandle becomes writable (such as during transport
       negotiation or SSL key management, for example).

   $stream->close
       A synonym for "close_when_empty". This should not be used when the deferred wait behaviour
       is required, as the behaviour of "close" may change in a future version of "IO::Async".
       Instead, call "close_when_empty" directly.

   $stream->close_when_empty
       If the write buffer is empty, this method calls "close" on the underlying IO handles, and
       removes the stream from its containing loop. If the write buffer still contains data, then
       this is deferred until the buffer is empty. This is intended for "write-then-close" one-
       shot streams.

        $stream->write( "Here is my final data\n" );
        $stream->close_when_empty;

       Because of this deferred nature, it may not be suitable for error handling.  See instead
       the "close_now" method.

   $stream->close_now
       This method immediately closes the underlying IO handles and removes the stream from the
       containing loop. It will not wait to flush the remaining data in the write buffer.

   $eof = $stream->is_read_eof
   $eof = $stream->is_write_eof
       Returns true after an EOF condition is reported on either the read or the write handle,
       respectively.

   $stream->write( $data, %params )
       This method adds data to the outgoing data queue, or writes it immediately, according to
       the "autoflush" parameter.

       If the "autoflush" option is set, this method will try immediately to write the data to
       the underlying filehandle. If this completes successfully then it will have been written
       by the time this method returns. If it fails to write completely, then the data is queued
       as if "autoflush" were not set, and will be flushed as normal.

       $data can either be a plain string, a Future, or a CODE reference. If it is a plain string
       it is written immediately. If it is not, its value will be used to generate more $data
       values, eventually leading to strings to be written.

       If $data is a "Future", the Stream will wait until it is ready, and take the single value
       it yields.

       If $data is a CODE reference, it will be repeatedly invoked to generate new values. Each
       time the filehandle is ready to write more data to it, the function is invoked. Once the
       function has finished generating data it should return undef. The function is passed the
       Stream object as its first argument.

       It is allowed that "Future"s yield CODE references, or CODE references return "Future"s,
       as well as plain strings.

       For example, to stream the contents of an existing opened filehandle:

        open my $fileh, "<", $path or die "Cannot open $path - $!";

        $stream->write( sub {
           my ( $stream ) = @_;

           sysread $fileh, my $buffer, 8192 or return;
           return $buffer;
        } );

       Takes the following optional named parameters in %params:

       write_len => INT
               Overrides the "write_len" parameter for the data written by this call.

       on_write => CODE
               A CODE reference which will be invoked after every successful "syswrite" operation
               on the underlying filehandle. It will be passed the number of bytes that were
               written by this call, which may not be the entire length of the buffer - if it
               takes more than one "syscall" operation to empty the buffer then this callback
               will be invoked multiple times.

                $on_write->( $stream, $len )

       on_flush => CODE
               A CODE reference which will be invoked once the data queued by this "write" call
               has been flushed. This will be invoked even if the buffer itself is not yet empty;
               if more data has been queued since the call.

                $on_flush->( $stream )

       If the object is not yet a member of a loop and doesn't yet have a "write_handle", then
       calls to the "write" method will simply queue the data and return. It will be flushed when
       the object is added to the loop.

       If $data is a defined but empty string, the write is still queued, and the "on_flush"
       continuation will be invoked, if supplied. This can be used to obtain a marker, to invoke
       some code once the output queue has been flushed up to this point.

   $f = $stream->write( ... )
       If called in non-void context, this method returns a Future which will complete (with no
       value) when the write operation has been flushed. This may be used as an alternative to,
       or combined with, the "on_flush" callback.

   $stream->push_on_read( $on_read )
       Pushes a new temporary "on_read" handler to the end of the queue. This queue, if non-
       empty, is used to provide "on_read" event handling code in preference to using the
       object's main event handler or method. New handlers can be supplied at any time, and they
       will be used in first-in first-out (FIFO) order.

       As with the main "on_read" event handler, each can return a (defined) boolean to indicate
       if they wish to be invoked again or not, another "CODE" reference to replace themself
       with, or "undef" to indicate it is now complete and should be removed. When a temporary
       handler returns "undef" it is shifted from the queue and the next one, if present, is
       invoked instead. If there are no more then the object's main handler is invoked instead.

FUTURE-RETURNING READ METHODS

       The following methods all return a Future which will become ready when enough data has
       been read by the Stream into its buffer. At this point, the data is removed from the
       buffer and given to the "Future" object to complete it.

        my $f = $stream->read_...

        my ( $string ) = $f->get;

       Unlike the "on_read" event handlers, these methods don't allow for access to "partial"
       results; they only provide the final result once it is ready.

       If a "Future" is cancelled before it completes it is removed from the read queue without
       consuming any data; i.e. each "Future" atomically either completes or is cancelled.

       Since it is possible to use a readable "Stream" entirely using these "Future"-returning
       methods instead of the "on_read" event, it may be useful to configure a trivial return-
       false event handler to keep it from consuming any input, and to allow it to be added to a
       "Loop" in the first place.

        my $stream = IO::Async::Stream->new( on_read => sub { 0 }, ... );
        $loop->add( $stream );

        my $f = $stream->read_...

       If a read EOF or error condition happens while there are read "Future"s pending, they are
       all completed. In the case of a read EOF, they are done with "undef"; in the case of a
       read error they are failed using the $! error value as the failure.

        $f->fail( $message, sysread => $! )

       If a read EOF condition happens to the currently-processing read "Future", it will return
       a partial result. The calling code can detect this by the fact that the returned data is
       not complete according to the specification (too short in "read_exactly"'s case, or
       lacking the ending pattern in "read_until"'s case). Additionally, each "Future" will yield
       the $eof value in its results.

        my ( $string, $eof ) = $f->get;

   $f = $stream->read_atmost( $len )
   $f = $stream->read_exactly( $len )
       Completes the "Future" when the read buffer contains $len or more characters of input.
       "read_atmost" will also complete after the first invocation of "on_read", even if fewer
       characters are available, whereas "read_exactly" will wait until at least $len are
       available.

   $f = $stream->read_until( $end )
       Completes the "Future" when the read buffer contains a match for $end, which may either be
       a plain string or a compiled "Regexp" reference. Yields the prefix of the buffer before
       and including this match.

   $f = $stream->read_until_eof
       Completes the "Future" when the stream is eventually closed at EOF, and yields all of the
       data that was available.

UTILITY CONSTRUCTORS

   $stream = IO::Async::Stream->new_for_stdin
   $stream = IO::Async::Stream->new_for_stdout
   $stream = IO::Async::Stream->new_for_stdio
       Return a "IO::Async::Stream" object preconfigured with the correct "read_handle",
       "write_handle" or both.

   $future = $stream->connect( %args )
       A convenient wrapper for calling the "connect" method on the underlying IO::Async::Loop
       object, passing the "socktype" hint as "stream" if not otherwise supplied.

EXAMPLES

   A line-based "on_read" method
       The following "on_read" method accepts incoming "\n"-terminated lines and prints them to
       the program's "STDOUT" stream.

        sub on_read
        {
           my $self = shift;
           my ( $buffref, $eof ) = @_;

           while( $$buffref =~ s/^(.*\n)// ) {
              print "Received a line: $1";
           }

           return 0;
        }

       Because a reference to the buffer itself is passed, it is simple to use a "s///" regular
       expression on the scalar it points at, to both check if data is ready (i.e. a whole line),
       and to remove it from the buffer. If no data is available then 0 is returned, to indicate
       it should not be tried again. If a line was successfully extracted, then 1 is returned, to
       indicate it should try again in case more lines exist in the buffer.

       For implementing real network protocols that are based on lines of text it may be more
       appropriate to use a subclass of IO::Async::Protocol::LineStream.

   Reading binary data
       This "on_read" method accepts incoming records in 16-byte chunks, printing each one.

        sub on_read
        {
           my ( $self, $buffref, $eof ) = @_;

           if( length $$buffref >= 16 ) {
              my $record = substr( $$buffref, 0, 16, "" );
              print "Received a 16-byte record: $record\n";

              return 1;
           }

           if( $eof and length $$buffref ) {
              print "EOF: a partial record still exists\n";
           }

           return 0;
        }

       The 4-argument form of "substr()" extracts the 16-byte record from the buffer and assigns
       it to the $record variable, if there was enough data in the buffer to extract it.

       A lot of protocols use a fixed-size header, followed by a variable-sized body of data,
       whose size is given by one of the fields of the header. The following "on_read" method
       extracts messages in such a protocol.

        sub on_read
        {
           my ( $self, $buffref, $eof ) = @_;

           return 0 unless length $$buffref >= 8; # "N n n" consumes 8 bytes

           my ( $len, $x, $y ) = unpack $$buffref, "N n n";

           return 0 unless length $$buffref >= 8 + $len;

           substr( $$buffref, 0, 8, "" );
           my $data = substr( $$buffref, 0, $len, "" );

           print "A record with values x=$x y=$y\n";

           return 1;
        }

       In this example, the header is "unpack()"ed first, to extract the body length, and then
       the body is extracted. If the buffer does not have enough data yet for a complete message
       then 0 is returned, and the buffer is left unmodified for next time. Only when there are
       enough bytes in total does it use "substr()" to remove them.

   Dynamic replacement of "on_read"
       Consider the following protocol (inspired by IMAP), which consists of "\n"-terminated
       lines that may have an optional data block attached. The presence of such a data block, as
       well as its size, is indicated by the line prefix.

        sub on_read
        {
           my $self = shift;
           my ( $buffref, $eof ) = @_;

           if( $$buffref =~ s/^DATA (\d+):(.*)\n// ) {
              my $length = $1;
              my $line   = $2;

              return sub {
                 my $self = shift;
                 my ( $buffref, $eof ) = @_;

                 return 0 unless length $$buffref >= $length;

                 # Take and remove the data from the buffer
                 my $data = substr( $$buffref, 0, $length, "" );

                 print "Received a line $line with some data ($data)\n";

                 return undef; # Restore the original method
              }
           }
           elsif( $$buffref =~ s/^LINE:(.*)\n// ) {
              my $line = $1;

              print "Received a line $line with no data\n";

              return 1;
           }
           else {
              print STDERR "Unrecognised input\n";
              # Handle it somehow
           }
        }

       In the case where trailing data is supplied, a new temporary "on_read" callback is
       provided in a closure. This closure captures the $length variable so it knows how much
       data to expect. It also captures the $line variable so it can use it in the event report.
       When this method has finished reading the data, it reports the event, then restores the
       original method by returning "undef".

SEE ALSO

       •   IO::Handle - Supply object methods for I/O handles

AUTHOR

       Paul Evans <leonerd@leonerd.org.uk>