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() 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() 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() 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() 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() 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() 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.
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.