Constructor

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

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() 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_output_filter POE_FILTER

get_input_filter

There is no get_filter() method because there is no sane return value when input and output filters differ.

get_output_filter

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

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

POE::Wheel::ReadWrite objects will emit a LowEvent when their output buffers shrink to LOW_MARK_OCTETS after having reached HIGH_MARK_OCTETS.

ID

pause_input

resume_input

get_input_handle

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

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

Occasionally, the POE::Wheel::ReadWrite object will stop monitoring its input filehandle for new data. This occurs regardless of the filehandle type.

shutdown_output

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

get_driver_out_messages

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

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.