| Current File : //usr/local/share/man/man3/POE::Wheel::ReadWrite.3pm |
.\" Automatically generated by Pod::Man 4.11 (Pod::Simple 3.35)
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. \*(C+ will
.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
.\" nothing in troff, for use with C<>.
.tr \(*W-
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
. ds C`
. ds C'
'br\}
.\"
.\" Escape single quotes in literal strings from groff's Unicode transform.
.ie \n(.g .ds Aq \(aq
.el .ds Aq '
.\"
.\" If the F register is >0, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.\"
.\" Avoid warning from groff about undefined register 'F'.
.de IX
..
.nr rF 0
.if \n(.g .if rF .nr rF 1
.if (\n(rF:(\n(.g==0)) \{\
. if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. if !\nF==2 \{\
. nr % 0
. nr F 2
. \}
. \}
.\}
.rr rF
.\" ========================================================================
.\"
.IX Title "POE::Wheel::ReadWrite 3"
.TH POE::Wheel::ReadWrite 3 "2022-03-23" "perl v5.26.3" "User Contributed Perl Documentation"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
.nh
.SH "NAME"
POE::Wheel::ReadWrite \- non\-blocking buffered I/O mix\-in for POE::Session
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
.Vb 1
\& #!perl
\&
\& use warnings;
\& use strict;
\&
\& use IO::Socket::INET;
\& use POE qw(Wheel::ReadWrite);
\&
\& POE::Session\->create(
\& inline_states => {
\& _start => sub {
\& # Note: IO::Socket::INET will block. We recommend
\& # POE::Wheel::SocketFactory or POE::Component::Client::TCP if
\& # blocking is contraindicated.
\& $_[HEAP]{client} = POE::Wheel::ReadWrite\->new(
\& Handle => IO::Socket::INET\->new(
\& PeerHost => \*(Aqwww.yahoo.com\*(Aq,
\& PeerPort => 80,
\& ),
\& InputEvent => \*(Aqon_remote_data\*(Aq,
\& ErrorEvent => \*(Aqon_remote_fail\*(Aq,
\& );
\&
\& print "Connected. Sending request...\en";
\& $_[HEAP]{client}\->put(
\& "GET / HTTP/0.9",
\& "Host: www.yahoo.com",
\& "",
\& );
\& },
\& on_remote_data => sub {
\& print "Received: $_[ARG0]\en";
\& },
\& on_remote_fail => sub {
\& print "Connection failed or ended. Shutting down...\en";
\& delete $_[HEAP]{client};
\& },
\& },
\& );
\&
\& POE::Kernel\->run();
\& exit;
.Ve
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
POE::Wheel::ReadWrite encapsulates a common design pattern: dealing
with buffered I/O in a non-blocking, event driven fashion.
.PP
The pattern goes something like this:
.PP
Given a filehandle, watch it for incoming data. When notified of
incoming data, read it, buffer it, and parse it according to some
low-level protocol (such as line-by-line). Generate higher-level
\&\*(L"here be lines\*(R" events, one per parsed line.
.PP
In the other direction, accept whole chunks of data (such as lines)
for output. Reformat them according to some low-level protocol (such
as by adding newlines), and buffer them for output. Flush the
buffered data when the filehandle is ready to transmit it.
.SH "PUBLIC METHODS"
.IX Header "PUBLIC METHODS"
.SS "Constructor"
.IX Subsection "Constructor"
POE::Wheel subclasses tend to perform a lot of setup so that they run
lighter and faster. POE::Wheel::ReadWrite's constructor is no
exception.
.PP
\fInew\fR
.IX Subsection "new"
.PP
\&\fBnew()\fR creates and returns a new POE:Wheel::ReadWrite instance. Under
most circumstances, the wheel will continue to read/write to one or
more filehandles until it's destroyed.
.PP
Handle
.IX Subsection "Handle"
.PP
Handle defines the filehandle that a POE::Wheel::ReadWrite object will
read from and write to. The \*(L"\s-1SYNOPSIS\*(R"\s0 includes an example using
Handle.
.PP
A single POE::Wheel::ReadWrite object can read from and write to different
filehandles. See \*(L"InputHandle\*(R" for more information and an example.
.PP
InputHandle
.IX Subsection "InputHandle"
.PP
InputHandle and OutputHandle may be used to specify different handles
for input and output. For example, input may be from \s-1STDIN\s0 and output
may go to \s-1STDOUT:\s0
.PP
.Vb 5
\& $_[HEAP]{console} = POE::Wheel::ReadWrite\->new(
\& InputHandle => \e*STDIN,
\& OutputHandle => \e*STDOUT,
\& InputEvent => "console_input",
\& );
.Ve
.PP
InputHandle and OutputHandle may not be used with Handle.
.PP
OutputHandle
.IX Subsection "OutputHandle"
.PP
InputHandle and OutputHandle may be used to specify different handles
for input and output. Please see \*(L"InputHandle\*(R" for more information
and an example.
.PP
Driver
.IX Subsection "Driver"
.PP
Driver specifies how POE::Wheel::ReadWrite will actually read from and
write to its filehandle or filehandles. Driver must be an object that
inherits from POE::Driver.
.PP
POE::Driver::SysRW, which implements \fBsysread()\fR and \fBsyswrite()\fR, is the
default. It's used in nearly all cases, so there's no point in
specifying it.
.PP
Filter
.IX Subsection "Filter"
.PP
Filter is the parser that POE::Wheel::ReadWrite will used to recognize
input data and the serializer it uses to prepare data for writing. It
defaults to a new POE::Filter::Line instance since many network
protocols are line based.
.PP
InputFilter
.IX Subsection "InputFilter"
.PP
InputFilter and OutputFilter may be used to specify different filters
for input and output.
.PP
OutputFilter
.IX Subsection "OutputFilter"
.PP
InputFilter and OutputFilter may be used to specify different filters
for input and output. Please see \*(L"InputFilter\*(R" for more information
and an example.
.PP
InputEvent
.IX Subsection "InputEvent"
.PP
InputEvent specifies the name of the event that will be sent for every
complete input unit (as parsed by InputFilter or Filter).
.PP
Every input event includes two parameters:
.PP
\&\f(CW\*(C`ARG0\*(C'\fR contains the parsed input unit, and \f(CW\*(C`ARG1\*(C'\fR contains the
unique \s-1ID\s0 for the POE::Wheel::ReadWrite object that generated the
event.
.PP
InputEvent is optional. If omitted, the POE::Wheel::ReadWrite object
will not watch its Handle or InputHandle for input, and no input
events will be generated.
.PP
A sample InputEvent handler:
.PP
.Vb 5
\& sub handle_input {
\& my ($heap, $input, $wheel_id) = @_[HEAP, ARG0, ARG1];
\& print "Echoing input from wheel $wheel_id: $input\en";
\& $heap\->{wheel}\->put($input); # Put... the input... beck!
\& }
.Ve
.PP
FlushedEvent
.IX Subsection "FlushedEvent"
.PP
FlushedEvent specifies the event that a POE::Wheel::ReadWrite object
will emit whenever its output buffer transitions from containing data
to becoming empty.
.PP
FlushedEvent comes with a single parameter: \f(CW\*(C`ARG0\*(C'\fR contains the
unique \s-1ID\s0 for the POE::Wheel::ReadWrite object that generated the
event. This may be used to match the event to a particular wheel.
.PP
\&\*(L"Flushed\*(R" events are often used to shut down I/O after a \*(L"goodbye\*(R"
message has been sent. For example, the following \fBinput_handler()\fR
responds to \*(L"quit\*(R" by instructing the wheel to say \*(L"Goodbye.\*(R" and then
to send a \*(L"shutdown\*(R" event when that has been flushed to the socket.
.PP
.Vb 3
\& sub handle_input {
\& my ($input, $wheel_id) = @_[ARG0, ARG1];
\& my $wheel = $_[HEAP]{wheel}{$wheel_id};
\&
\& if ($input eq "quit") {
\& $wheel\->event( FlushedEvent => "shutdown" );
\& $wheel\->put("Goodbye.");
\& }
\& else {
\& $wheel\->put("Echo: $input");
\& }
\& }
.Ve
.PP
Here's the shutdown handler. It just destroys the wheel to end the
connection:
.PP
.Vb 4
\& sub handle_flushed {
\& my $wheel_id = $_[ARG0];
\& delete $_[HEAP]{wheel}{$wheel_id};
\& }
.Ve
.PP
ErrorEvent
.IX Subsection "ErrorEvent"
.PP
ErrorEvent names the event that a POE::Wheel::ReadWrite object will
emit whenever an error occurs. Every ErrorEvent includes four
parameters:
.PP
\&\f(CW\*(C`ARG0\*(C'\fR describes what failed, either \*(L"read\*(R" or \*(L"write\*(R". It doesn't
name a particular function since POE::Wheel::ReadWrite delegates
actual reading and writing to a POE::Driver object.
.PP
\&\f(CW\*(C`ARG1\*(C'\fR and \f(CW\*(C`ARG2\*(C'\fR hold numeric and string values for \f(CW$!\fR at the
time of failure. Applicatin code cannot test \f(CW$!\fR directly since its
value may have changed between the time of the error and the time the
error event is dispatched.
.PP
\&\f(CW\*(C`ARG3\*(C'\fR contains the wheel's unique \s-1ID.\s0 The wheel's \s-1ID\s0 is used to
differentiate between many wheels managed by a single session.
.PP
ErrorEvent may also indicate \s-1EOF\s0 on a FileHandle by returning
operation \*(L"read\*(R" error 0. For sockets, this means the remote end has
closed the connection.
.PP
A sample ErrorEvent handler:
.PP
.Vb 10
\& sub error_state {
\& my ($operation, $errnum, $errstr, $id) = @_[ARG0..ARG3];
\& if ($operation eq "read" and $errnum == 0) {
\& print "EOF from wheel $id\en";
\& }
\& else {
\& warn "Wheel $id encountered $operation error $errnum: $errstr\en";
\& }
\& delete $_[HEAP]{wheels}{$id}; # shut down that wheel
\& }
.Ve
.PP
HighEvent
.IX Subsection "HighEvent"
.PP
HighEvent and LowEvent are used along with HighMark and LowMark to
control the flow of streamed output.
.PP
A HighEvent is sent when the output buffer of a POE::Wheel::ReadWrite
object exceeds a certain size (the \*(L"high water\*(R" mark, or HighMark).
This advises an application to stop streaming output. \s-1POE\s0 and Perl
really don't care if the application continues, but it's possible that
the process may run out of memory if a buffer grows without bounds.
.PP
A POE::Wheel::ReadWrite object will continue to flush its buffer even
after an application stops streaming data, until the buffer is empty.
Some streaming applications may require the buffer to always be primed
with data, however. For example, a media server would encounter
stutters if it waited for a FlushedEvent before sending more data.
.PP
LowEvent solves the stutter problem. A POE::Wheel::ReadWrite object
will send a LowEvent when its output buffer drains below a certain
level (the \*(L"low water\*(R" mark, or LowMark). This notifies an
application that the buffer is small enough that it may resume
streaming.
.PP
The stutter problem is solved because the output buffer never quite
reaches empty.
.PP
HighEvent and LowEvent are edge-triggered, not level-triggered. This
means they are emitted once whenever a POE::Wheel::ReadWrite object's
output buffer crosses the HighMark or LowMark. If an application
continues to \fBput()\fR data after the HighMark is reached, it will not
cause another HighEvent to be sent.
.PP
HighEvent is generally not needed. The \fBput()\fR method will return the
high watermark state: true if the buffer is at or above the high
watermark, or false if the buffer has room for more data. Here's a
quick way to prime a POE::Wheel::ReadWrite object's output buffer:
.PP
.Vb 1
\& 1 while not $_[HEAP]{readwrite}\->put(get_next_data());
.Ve
.PP
POE::Wheel::ReadWrite objects always start in a low-water state.
.PP
HighEvent and LowEvent are optional. Omit them if flow control is not
needed.
.PP
LowEvent
.IX Subsection "LowEvent"
.PP
HighEvent and LowEvent are used along with HighMark and LowMark to
control the flow of streamed output. Please see \*(L"HighEvent\*(R" for
more information and examples.
.SS "put \s-1RECORDS\s0"
.IX Subsection "put RECORDS"
\&\fBput()\fR accepts a list of \s-1RECORDS,\s0 which will be serialized by the
wheel's Filter and buffered and written by its Driver.
.PP
\&\fBput()\fR returns true if a HighMark has been set and the Driver's output
buffer has reached or exceeded the limit. False is returned if
HighMark has not been set, or if the Driver's buffer is smaller than
that limit.
.PP
\&\fBput()\fR's return value is purely advisory; an application may continue
buffering data beyond the HighMark\-\-\-at the risk of exceeding the
process' memory limits. Do not use \f(CW\*(C`<1 while not $wheel\-\*(C'\fR\fBput()\fR>>
syntax if HighMark isn't set: the application will fail spectacularly!
.SS "event \s-1EVENT_TYPE\s0 => \s-1EVENT_NAME, ...\s0"
.IX Subsection "event EVENT_TYPE => EVENT_NAME, ..."
\&\fBevent()\fR allows an application to modify the events emitted by a
POE::Wheel::ReadWrite object. All constructor parameters ending in
\&\*(L"Event\*(R" may be changed at run time: \*(L"InputEvent\*(R", \*(L"FlushedEvent\*(R",
\&\*(L"ErrorEvent\*(R", \*(L"HighEvent\*(R", and \*(L"LowEvent\*(R".
.PP
Setting an event to undef will disable the code within the wheel that
generates the event. So for example, stopping InputEvent will also
stop reading from the filehandle. \*(L"pause_input\*(R" and
\&\*(L"resume_input\*(R" may be a better way to manage input events, however.
.SS "set_filter \s-1POE_FILTER\s0"
.IX Subsection "set_filter POE_FILTER"
\&\fBset_filter()\fR changes the way a POE::Wheel::ReadWrite object parses
input and serializes output. Any pending data that has not been
dispatched to the application will be parsed with the new \s-1POE_FILTER.\s0
Information that has been \fBput()\fR but not flushed will not be
reserialized.
.PP
\&\fBset_filter()\fR performs the same act as calling \fBset_input_filter()\fR
and \fBset_output_filter()\fR with the same POE::Filter object.
.PP
Switching filters can be tricky. Please see the discussion of
\&\fBget_pending()\fR in POE::Filter. Some filters may not support being
dynamically loaded or unloaded.
.SS "set_input_filter \s-1POE_FILTER\s0"
.IX Subsection "set_input_filter POE_FILTER"
\&\fBset_input_filter()\fR changes a POE::Wheel::ReadWrite object's input
filter while leaving the output filter unchanged. This alters the way
data is parsed without affecting how it's serialized for output.
.SS "set_output_filter \s-1POE_FILTER\s0"
.IX Subsection "set_output_filter POE_FILTER"
\&\fBset_output_filter()\fR changes how a POE::Wheel::ReadWrite object
serializes its output but does not affect the way data is parsed.
.SS "get_input_filter"
.IX Subsection "get_input_filter"
\&\fBget_input_filter()\fR returns the POE::Filter object currently used by a
POE::Wheel::ReadWrite object to parse incoming data. The returned
object may be introspected or altered via its own methods.
.PP
There is no \fBget_filter()\fR method because there is no sane return value
when input and output filters differ.
.SS "get_output_filter"
.IX Subsection "get_output_filter"
\&\fBget_output_filter()\fR returns the POE::Filter object currently used by a
POE::Wheel::ReadWrite object to serialize outgoing data. The returned
object may be introspected or altered via its own methods.
.PP
There is no \fBget_filter()\fR method because there is no sane return value
when input and output filters differ.
.SS "set_high_mark \s-1HIGH_MARK_OCTETS\s0"
.IX Subsection "set_high_mark HIGH_MARK_OCTETS"
Sets the high water mark\-\-\-the number of octets that designates a
\&\*(L"full enough\*(R" output buffer. A POE::Wheel::ReadWrite object will emit
a HighEvent when its output buffer expands to reach this point. All
\&\fBput()\fR calls will return true when the output buffer is equal or
greater than \s-1HIGH_MARK_OCTETS.\s0
.PP
Both HighEvent and \fBput()\fR indicate that it's unsafe to continue writing
when the output buffer expands to at least \s-1HIGH_MARK_OCTETS.\s0
.SS "set_low_mark \s-1LOW_MARK_OCTETS\s0"
.IX Subsection "set_low_mark LOW_MARK_OCTETS"
Sets the low water mark\-\-\-the number of octets that designates an
\&\*(L"empty enough\*(R" output buffer. This event lets an application know
that it's safe to resume writing again.
.PP
POE::Wheel::ReadWrite objects will emit a LowEvent when their output
buffers shrink to \s-1LOW_MARK_OCTETS\s0 after having reached
\&\s-1HIGH_MARK_OCTETS.\s0
.SS "\s-1ID\s0"
.IX Subsection "ID"
\&\s-1\fBID\s0()\fR returns a POE::Wheel::ReadWrite object's unique \s-1ID.\s0 \s-1\fBID\s0()\fR is
usually called after the object is created so that the object may be
stashed by its \s-1ID.\s0 Events generated by the POE::Wheel::ReadWrite
object will include the \s-1ID\s0 of the object, so that they may be matched
back to their sources.
.SS "pause_input"
.IX Subsection "pause_input"
\&\fBpause_input()\fR instructs a POE::Wheel::ReadWrite object to stop
watching for input, and thus stop emitting InputEvent events. It's
much more efficient than destroying the object outright, especially if
an application intends to \fBresume_input()\fR later.
.SS "resume_input"
.IX Subsection "resume_input"
\&\fBresume_input()\fR turns a POE::Wheel::ReadWrite object's input watcher
back on. It's used to resume watching for input, and thus resume
sending InputEvent events. \fBpause_input()\fR and \fBresume_input()\fR implement
a form of input flow control, driven by the application itself.
.SS "get_input_handle"
.IX Subsection "get_input_handle"
\&\fBget_input_handle()\fR returns the filehandle being watched for input.
.PP
Manipulating filehandles that are managed by \s-1POE\s0 may cause nasty side
effects, which may change from one \s-1POE\s0 release to the next. Please
use caution.
.SS "get_output_handle"
.IX Subsection "get_output_handle"
\&\fBget_output_handle()\fR returns the filehandle being watched for output.
.PP
Manipulating filehandles that are managed by \s-1POE\s0 may cause nasty side
effects, which may change from one \s-1POE\s0 release to the next. Please
use caution.
.SS "shutdown_input"
.IX Subsection "shutdown_input"
Call shutdown($fh,0) on a POE::Wheel::ReadWrite object's input
filehandle. This only works for sockets; nothing will happen for
other types of filehandle.
.PP
Occasionally, the POE::Wheel::ReadWrite object will stop monitoring
its input filehandle for new data. This occurs regardless of the
filehandle type.
.SS "shutdown_output"
.IX Subsection "shutdown_output"
Call shutdown($fh,1) on a POE::Wheel::ReadWrite object's output
filehandle. This only works for sockets; nothing will happen for
other types of filehandle.
.PP
Occasionally, the POE::Wheel::ReadWrite object will stop monitoring its
output filehandle for new data. This occurs regardless of the
filehandle type.
.SS "get_driver_out_octets"
.IX Subsection "get_driver_out_octets"
POE::Driver objects contain output buffers that are flushed
asynchronously. \fBget_driver_out_octets()\fR returns the number of octets
remaining in the wheel's driver's output buffer.
.SS "get_driver_out_messages"
.IX Subsection "get_driver_out_messages"
POE::Driver objects' output buffers may be message based. Every \fBput()\fR
call may be buffered individually. \fBget_driver_out_messages()\fR will
return the number of pending \fBput()\fR messages that remain to be sent.
.PP
Stream-based drivers will simply return 1 if any data remains to be
flushed. This is because they operate with one potentially large
message.
.SS "flush"
.IX Subsection "flush"
\&\fBflush()\fR manually attempts to flush a wheel's output in a synchronous
fashion. This can be used to flush small messages. Note, however,
that complete flushing is not guaranteed\-\-\-to do so would mean
potentially blocking indefinitely, which is undesirable in most \s-1POE\s0
applications.
.PP
If an application must guarantee a full buffer flush, it may loop
\&\fBflush()\fR calls:
.PP
.Vb 1
\& $wheel\->flush() while $wheel\->get_driver_out_octets();
.Ve
.PP
However it would be prudent to check for errors as well. A \fBflush()\fR
failure may be permanent, and an infinite loop is probably not what
most developers have in mind here.
.PP
It should be obvious by now that \fBthis method is experimental\fR. Its
behavior may change or it may disappear outright. Please let us know
whether it's useful.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
POE::Wheel describes wheels in general.
.PP
The \s-1SEE ALSO\s0 section in \s-1POE\s0 contains a table of contents covering
the entire \s-1POE\s0 distribution.
.SH "BUGS"
.IX Header "BUGS"
None known.
.SH "AUTHORS & COPYRIGHTS"
.IX Header "AUTHORS & COPYRIGHTS"
Please see \s-1POE\s0 for more information about authors and contributors.