bionic (3) POE::Wheel::ReadWrite.3pm.gz
NAME
POE::Wheel::ReadWrite - non-blocking buffered I/O mix-in for POE::Session
SYNOPSIS
#!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 => 'www.yahoo.com',
PeerPort => 80,
),
InputEvent => 'on_remote_data',
ErrorEvent => 'on_remote_fail',
);
print "Connected. Sending request...\n";
$_[HEAP]{client}->put(
"GET / HTTP/0.9",
"Host: www.yahoo.com",
"",
);
},
on_remote_data => sub {
print "Received: $_[ARG0]\n";
},
on_remote_fail => sub {
print "Connection failed or ended. Shutting down...\n";
delete $_[HEAP]{client};
},
},
);
POE::Kernel->run();
exit;
DESCRIPTION
POE::Wheel::ReadWrite encapsulates a common design pattern: dealing with buffered I/O in a non-blocking,
event driven fashion.
The pattern goes something like this:
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 "here be
lines" events, one per parsed line.
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.
PUBLIC METHODS
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.
new
new() 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.
Handle
Handle defines the filehandle that a POE::Wheel::ReadWrite object will read from and write to. The
"SYNOPSIS" includes an example using Handle.
A single POE::Wheel::ReadWrite object can read from and write to different filehandles. See
"InputHandle" for more information and an example.
InputHandle
InputHandle and OutputHandle may be used to specify different handles for input and output. For example,
input may be from STDIN and output may go to STDOUT:
$_[HEAP]{console} = POE::Wheel::ReadWrite->new(
InputHandle => \*STDIN,
OutputHandle => \*STDOUT,
InputEvent => "console_input",
);
InputHandle and OutputHandle may not be used with Handle.
OutputHandle
InputHandle and OutputHandle may be used to specify different handles for input and output. Please see
"InputHandle" for more information and an example.
Driver
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.
POE::Driver::SysRW, which implements sysread() and syswrite(), is the default. It's used in nearly all
cases, so there's no point in specifying it.
Filter
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.
InputFilter
InputFilter and OutputFilter may be used to specify different filters for input and output.
OutputFilter
InputFilter and OutputFilter may be used to specify different filters for input and output. Please see
"InputFilter" for more information and an example.
InputEvent
InputEvent specifies the name of the event that will be sent for every complete input unit (as parsed by
InputFilter or Filter).
Every input event includes two parameters:
"ARG0" contains the parsed input unit, and "ARG1" contains the unique ID for the POE::Wheel::ReadWrite
object that generated the event.
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.
A sample InputEvent handler:
sub handle_input {
my ($heap, $input, $wheel_id) = @_[HEAP, ARG0, ARG1];
print "Echoing input from wheel $wheel_id: $input\n";
$heap->{wheel}->put($input); # Put... the input... beck!
}
FlushedEvent
FlushedEvent specifies the event that a POE::Wheel::ReadWrite object will emit whenever its output buffer
transitions from containing data to becoming empty.
FlushedEvent comes with a single parameter: "ARG0" contains the unique ID for the POE::Wheel::ReadWrite
object that generated the event. This may be used to match the event to a particular wheel.
"Flushed" events are often used to shut down I/O after a "goodbye" message has been sent. For example,
the following input_handler() responds to "quit" by instructing the wheel to say "Goodbye." and then to
send a "shutdown" event when that has been flushed to the socket.
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");
}
}
Here's the shutdown handler. It just destroys the wheel to end the connection:
sub handle_flushed {
my $wheel_id = $_[ARG0];
delete $_[HEAP]{wheel}{$wheel_id};
}
ErrorEvent
ErrorEvent names the event that a POE::Wheel::ReadWrite object will emit whenever an error occurs. Every
ErrorEvent includes four parameters:
"ARG0" describes what failed, either "read" or "write". It doesn't name a particular function since
POE::Wheel::ReadWrite delegates actual reading and writing to a POE::Driver object.
"ARG1" and "ARG2" hold numeric and string values for $! at the time of failure. Applicatin code cannot
test $! directly since its value may have changed between the time of the error and the time the error
event is dispatched.
"ARG3" contains the wheel's unique ID. The wheel's ID is used to differentiate between many wheels
managed by a single session.
ErrorEvent may also indicate EOF on a FileHandle by returning operation "read" error 0. For sockets,
this means the remote end has closed the connection.
A sample ErrorEvent handler:
sub error_state {
my ($operation, $errnum, $errstr, $id) = @_[ARG0..ARG3];
if ($operation eq "read" and $errnum == 0) {
print "EOF from wheel $id\n";
}
else {
warn "Wheel $id encountered $operation error $errnum: $errstr\n";
}
delete $_[HEAP]{wheels}{$id}; # shut down that wheel
}
HighEvent
HighEvent and LowEvent are used along with HighMark and LowMark to control the flow of streamed output.
A HighEvent is sent when the output buffer of a POE::Wheel::ReadWrite object exceeds a certain size (the
"high water" mark, or HighMark). This advises an application to stop streaming output. POE 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.
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.
LowEvent solves the stutter problem. A POE::Wheel::ReadWrite object will send a LowEvent when its output
buffer drains below a certain level (the "low water" mark, or LowMark). This notifies an application
that the buffer is small enough that it may resume streaming.
The stutter problem is solved because the output buffer never quite reaches empty.
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 put() data after the HighMark is reached, it will not cause another HighEvent to
be sent.
HighEvent is generally not needed. The put() 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:
1 while not $_[HEAP]{readwrite}->put(get_next_data());
POE::Wheel::ReadWrite objects always start in a low-water state.
HighEvent and LowEvent are optional. Omit them if flow control is not needed.
LowEvent
HighEvent and LowEvent are used along with HighMark and LowMark to control the flow of streamed output.
Please see "HighEvent" for more information and examples.
put RECORDS
put() accepts a list of RECORDS, which will be serialized by the wheel's Filter and buffered and written
by its Driver.
put() 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.
put()'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 "<1 while not $wheel-"put()>>
syntax if HighMark isn't set: the application will fail spectacularly!
event EVENT_TYPE => EVENT_NAME, ...
event() allows an application to modify the events emitted by a POE::Wheel::ReadWrite object. All
constructor parameters ending in "Event" may be changed at run time: "InputEvent", "FlushedEvent",
"ErrorEvent", "HighEvent", and "LowEvent".
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. "pause_input" and
"resume_input" may be a better way to manage input events, however.
set_filter POE_FILTER
set_filter() 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 POE_FILTER.
Information that has been put() but not flushed will not be reserialized.
set_filter() performs the same act as calling set_input_filter() and set_output_filter() with the same
POE::Filter object.
Switching filters can be tricky. Please see the discussion of get_pending() in POE::Filter. Some
filters may not support being dynamically loaded or unloaded.
set_input_filter POE_FILTER
set_input_filter() 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.
set_output_filter POE_FILTER
set_output_filter() changes how a POE::Wheel::ReadWrite object serializes its output but does not affect
the way data is parsed.
get_input_filter
get_input_filter() 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.
There is no get_filter() method because there is no sane return value when input and output filters
differ.
get_output_filter
get_output_filter() 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.
There is no get_filter() method because there is no sane return value when input and output filters
differ.
set_high_mark HIGH_MARK_OCTETS
Sets the high water mark---the number of octets that designates a "full enough" output buffer. A
POE::Wheel::ReadWrite object will emit a HighEvent when its output buffer expands to reach this point.
All put() calls will return true when the output buffer is equal or greater than HIGH_MARK_OCTETS.
Both HighEvent and put() indicate that it's unsafe to continue writing when the output buffer expands to
at least HIGH_MARK_OCTETS.
set_low_mark LOW_MARK_OCTETS
Sets the low water mark---the number of octets that designates an "empty enough" output buffer. This
event lets an application know that it's safe to resume writing again.
POE::Wheel::ReadWrite objects will emit a LowEvent when their output buffers shrink to LOW_MARK_OCTETS
after having reached HIGH_MARK_OCTETS.
ID
ID() returns a POE::Wheel::ReadWrite object's unique ID. ID() is usually called after the object is
created so that the object may be stashed by its ID. Events generated by the POE::Wheel::ReadWrite
object will include the ID of the object, so that they may be matched back to their sources.
pause_input
pause_input() 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 resume_input() later.
resume_input
resume_input() 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. pause_input() and resume_input()
implement a form of input flow control, driven by the application itself.
get_input_handle
get_input_handle() returns the filehandle being watched for input.
Manipulating filehandles that are managed by POE may cause nasty side effects, which may change from one
POE release to the next. Please use caution.
get_output_handle
get_output_handle() returns the filehandle being watched for output.
Manipulating filehandles that are managed by POE may cause nasty side effects, which may change from one
POE release to the next. Please use caution.
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.
Occasionally, the POE::Wheel::ReadWrite object will stop monitoring its input filehandle for new data.
This occurs regardless of the filehandle type.
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.
Occasionally, the POE::Wheel::ReadWrite object will stop monitoring its output filehandle for new data.
This occurs regardless of the filehandle type.
get_driver_out_octets
POE::Driver objects contain output buffers that are flushed asynchronously. get_driver_out_octets()
returns the number of octets remaining in the wheel's driver's output buffer.
get_driver_out_messages
POE::Driver objects' output buffers may be message based. Every put() call may be buffered individually.
get_driver_out_messages() will return the number of pending put() messages that remain to be sent.
Stream-based drivers will simply return 1 if any data remains to be flushed. This is because they
operate with one potentially large message.
flush
flush() 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 POE applications.
If an application must guarantee a full buffer flush, it may loop flush() calls:
$wheel->flush() while $wheel->get_driver_out_octets();
However it would be prudent to check for errors as well. A flush() failure may be permanent, and an
infinite loop is probably not what most developers have in mind here.
It should be obvious by now that this method is experimental. Its behavior may change or it may
disappear outright. Please let us know whether it's useful.
SEE ALSO
POE::Wheel describes wheels in general.
The SEE ALSO section in POE contains a table of contents covering the entire POE distribution.
BUGS
None known.
AUTHORS & COPYRIGHTS
Please see POE for more information about authors and contributors.