{ "content": [ { "type": "text", "text": "# POE::Wheel::ReadWrite (perldoc)\n\n## NAME\n\nPOE::Wheel::ReadWrite - non-blocking buffered I/O mix-in for POE::Session\n\n## SYNOPSIS\n\n#!perl\nuse warnings;\nuse strict;\nuse IO::Socket::INET;\nuse POE qw(Wheel::ReadWrite);\nPOE::Session->create(\ninlinestates => {\nstart => sub {\n# Note: IO::Socket::INET will block. We recommend\n# POE::Wheel::SocketFactory or POE::Component::Client::TCP if\n# blocking is contraindicated.\n$[HEAP]{client} = POE::Wheel::ReadWrite->new(\nHandle => IO::Socket::INET->new(\nPeerHost => 'www.yahoo.com',\nPeerPort => 80,\n),\nInputEvent => 'onremotedata',\nErrorEvent => 'onremotefail',\n);\nprint \"Connected. Sending request...\\n\";\n$[HEAP]{client}->put(\n\"GET / HTTP/0.9\",\n\"Host: www.yahoo.com\",\n\"\",\n);\n},\nonremotedata => sub {\nprint \"Received: $[ARG0]\\n\";\n},\nonremotefail => sub {\nprint \"Connection failed or ended. Shutting down...\\n\";\ndelete $[HEAP]{client};\n},\n},\n);\nPOE::Kernel->run();\nexit;\n\n## DESCRIPTION\n\nPOE::Wheel::ReadWrite encapsulates a common design pattern: dealing with buffered I/O in a\nnon-blocking, event driven fashion.\n\n## Sections\n\n- **NAME**\n- **SYNOPSIS**\n- **DESCRIPTION**\n- **PUBLIC METHODS** (18 subsections)\n- **SEE ALSO**\n- **BUGS**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n" } ], "structuredContent": { "command": "POE::Wheel::ReadWrite", "section": "", "mode": "perldoc", "summary": "POE::Wheel::ReadWrite - non-blocking buffered I/O mix-in for POE::Session", "synopsis": "#!perl\nuse warnings;\nuse strict;\nuse IO::Socket::INET;\nuse POE qw(Wheel::ReadWrite);\nPOE::Session->create(\ninlinestates => {\nstart => sub {\n# Note: IO::Socket::INET will block. We recommend\n# POE::Wheel::SocketFactory or POE::Component::Client::TCP if\n# blocking is contraindicated.\n$[HEAP]{client} = POE::Wheel::ReadWrite->new(\nHandle => IO::Socket::INET->new(\nPeerHost => 'www.yahoo.com',\nPeerPort => 80,\n),\nInputEvent => 'onremotedata',\nErrorEvent => 'onremotefail',\n);\nprint \"Connected. Sending request...\\n\";\n$[HEAP]{client}->put(\n\"GET / HTTP/0.9\",\n\"Host: www.yahoo.com\",\n\"\",\n);\n},\nonremotedata => sub {\nprint \"Received: $[ARG0]\\n\";\n},\nonremotefail => sub {\nprint \"Connection failed or ended. Shutting down...\\n\";\ndelete $[HEAP]{client};\n},\n},\n);\nPOE::Kernel->run();\nexit;", "tldr_summary": null, "tldr_examples": [], "tldr_source": null, "flags": [], "examples": [], "see_also": [], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "SYNOPSIS", "lines": 43, "subsections": [] }, { "name": "DESCRIPTION", "lines": 13, "subsections": [] }, { "name": "PUBLIC METHODS", "lines": 1, "subsections": [ { "name": "Constructor", "lines": 4 }, { "name": "new", "lines": 166 }, { "name": "put", "lines": 2 }, { "name": "put", "lines": 3 }, { "name": "put", "lines": 4 }, { "name": "event", "lines": 8 }, { "name": "set_filter", "lines": 3 }, { "name": "set_filter", "lines": 6 }, { "name": "set_input_filter", "lines": 4 }, { "name": "set_output_filter", "lines": 3 }, { "name": "get_input_filter", "lines": 7 }, { "name": "get_output_filter", "lines": 29 }, { "name": "pause_input", "lines": 4 }, { "name": "resume_input", "lines": 4 }, { "name": "get_input_handle", "lines": 4 }, { "name": "get_output_handle", "lines": 19 }, { "name": "get_driver_out_octets", "lines": 11 }, { "name": "flush", "lines": 13 } ] }, { "name": "SEE ALSO", "lines": 4, "subsections": [] }, { "name": "BUGS", "lines": 5, "subsections": [] } ], "sections": { "NAME": { "content": "POE::Wheel::ReadWrite - non-blocking buffered I/O mix-in for POE::Session\n", "subsections": [] }, "SYNOPSIS": { "content": "#!perl\n\nuse warnings;\nuse strict;\n\nuse IO::Socket::INET;\nuse POE qw(Wheel::ReadWrite);\n\nPOE::Session->create(\ninlinestates => {\nstart => sub {\n# Note: IO::Socket::INET will block. We recommend\n# POE::Wheel::SocketFactory or POE::Component::Client::TCP if\n# blocking is contraindicated.\n$[HEAP]{client} = POE::Wheel::ReadWrite->new(\nHandle => IO::Socket::INET->new(\nPeerHost => 'www.yahoo.com',\nPeerPort => 80,\n),\nInputEvent => 'onremotedata',\nErrorEvent => 'onremotefail',\n);\n\nprint \"Connected. Sending request...\\n\";\n$[HEAP]{client}->put(\n\"GET / HTTP/0.9\",\n\"Host: www.yahoo.com\",\n\"\",\n);\n},\nonremotedata => sub {\nprint \"Received: $[ARG0]\\n\";\n},\nonremotefail => sub {\nprint \"Connection failed or ended. Shutting down...\\n\";\ndelete $[HEAP]{client};\n},\n},\n);\n\nPOE::Kernel->run();\nexit;\n", "subsections": [] }, "DESCRIPTION": { "content": "POE::Wheel::ReadWrite encapsulates a common design pattern: dealing with buffered I/O in a\nnon-blocking, event driven fashion.\n\nThe pattern goes something like this:\n\nGiven a filehandle, watch it for incoming data. When notified of incoming data, read it, buffer\nit, and parse it according to some low-level protocol (such as line-by-line). Generate\nhigher-level \"here be lines\" events, one per parsed line.\n\nIn the other direction, accept whole chunks of data (such as lines) for output. Reformat them\naccording to some low-level protocol (such as by adding newlines), and buffer them for output.\nFlush the buffered data when the filehandle is ready to transmit it.\n", "subsections": [] }, "PUBLIC METHODS": { "content": "", "subsections": [ { "name": "Constructor", "content": "POE::Wheel subclasses tend to perform a lot of setup so that they run lighter and faster.\nPOE::Wheel::ReadWrite's constructor is no exception.\n\nnew" }, { "name": "new", "content": "wheel will continue to read/write to one or more filehandles until it's destroyed.\n\nHandle\nHandle defines the filehandle that a POE::Wheel::ReadWrite object will read from and write to.\nThe \"SYNOPSIS\" includes an example using Handle.\n\nA single POE::Wheel::ReadWrite object can read from and write to different filehandles. See\n\"InputHandle\" for more information and an example.\n\nInputHandle\nInputHandle and OutputHandle may be used to specify different handles for input and output. For\nexample, input may be from STDIN and output may go to STDOUT:\n\n$[HEAP]{console} = POE::Wheel::ReadWrite->new(\nInputHandle => \\*STDIN,\nOutputHandle => \\*STDOUT,\nInputEvent => \"consoleinput\",\n);\n\nInputHandle and OutputHandle may not be used with Handle.\n\nOutputHandle\nInputHandle and OutputHandle may be used to specify different handles for input and output.\nPlease see \"InputHandle\" for more information and an example.\n\nDriver\nDriver specifies how POE::Wheel::ReadWrite will actually read from and write to its filehandle\nor filehandles. Driver must be an object that inherits from POE::Driver.\n\nPOE::Driver::SysRW, which implements sysread() and syswrite(), is the default. It's used in\nnearly all cases, so there's no point in specifying it.\n\nFilter\nFilter is the parser that POE::Wheel::ReadWrite will used to recognize input data and the\nserializer it uses to prepare data for writing. It defaults to a new POE::Filter::Line instance\nsince many network protocols are line based.\n\nInputFilter\nInputFilter and OutputFilter may be used to specify different filters for input and output.\n\nOutputFilter\nInputFilter and OutputFilter may be used to specify different filters for input and output.\nPlease see \"InputFilter\" for more information and an example.\n\nInputEvent\nInputEvent specifies the name of the event that will be sent for every complete input unit (as\nparsed by InputFilter or Filter).\n\nEvery input event includes two parameters:\n\n\"ARG0\" contains the parsed input unit, and \"ARG1\" contains the unique ID for the\nPOE::Wheel::ReadWrite object that generated the event.\n\nInputEvent is optional. If omitted, the POE::Wheel::ReadWrite object will not watch its Handle\nor InputHandle for input, and no input events will be generated.\n\nA sample InputEvent handler:\n\nsub handleinput {\nmy ($heap, $input, $wheelid) = @[HEAP, ARG0, ARG1];\nprint \"Echoing input from wheel $wheelid: $input\\n\";\n$heap->{wheel}->put($input); # Put... the input... beck!\n}\n\nFlushedEvent\nFlushedEvent specifies the event that a POE::Wheel::ReadWrite object will emit whenever its\noutput buffer transitions from containing data to becoming empty.\n\nFlushedEvent comes with a single parameter: \"ARG0\" contains the unique ID for the\nPOE::Wheel::ReadWrite object that generated the event. This may be used to match the event to a\nparticular wheel.\n\n\"Flushed\" events are often used to shut down I/O after a \"goodbye\" message has been sent. For\nexample, the following inputhandler() responds to \"quit\" by instructing the wheel to say\n\"Goodbye.\" and then to send a \"shutdown\" event when that has been flushed to the socket.\n\nsub handleinput {\nmy ($input, $wheelid) = @[ARG0, ARG1];\nmy $wheel = $[HEAP]{wheel}{$wheelid};\n\nif ($input eq \"quit\") {\n$wheel->event( FlushedEvent => \"shutdown\" );\n$wheel->put(\"Goodbye.\");\n}\nelse {\n$wheel->put(\"Echo: $input\");\n}\n}\n\nHere's the shutdown handler. It just destroys the wheel to end the connection:\n\nsub handleflushed {\nmy $wheelid = $[ARG0];\ndelete $[HEAP]{wheel}{$wheelid};\n}\n\nErrorEvent\nErrorEvent names the event that a POE::Wheel::ReadWrite object will emit whenever an error\noccurs. Every ErrorEvent includes four parameters:\n\n\"ARG0\" describes what failed, either \"read\" or \"write\". It doesn't name a particular function\nsince POE::Wheel::ReadWrite delegates actual reading and writing to a POE::Driver object.\n\n\"ARG1\" and \"ARG2\" hold numeric and string values for $! at the time of failure. Applicatin code\ncannot test $! directly since its value may have changed between the time of the error and the\ntime the error event is dispatched.\n\n\"ARG3\" contains the wheel's unique ID. The wheel's ID is used to differentiate between many\nwheels managed by a single session.\n\nErrorEvent may also indicate EOF on a FileHandle by returning operation \"read\" error 0. For\nsockets, this means the remote end has closed the connection.\n\nA sample ErrorEvent handler:\n\nsub errorstate {\nmy ($operation, $errnum, $errstr, $id) = @[ARG0..ARG3];\nif ($operation eq \"read\" and $errnum == 0) {\nprint \"EOF from wheel $id\\n\";\n}\nelse {\nwarn \"Wheel $id encountered $operation error $errnum: $errstr\\n\";\n}\ndelete $[HEAP]{wheels}{$id}; # shut down that wheel\n}\n\nHighEvent\nHighEvent and LowEvent are used along with HighMark and LowMark to control the flow of streamed\noutput.\n\nA HighEvent is sent when the output buffer of a POE::Wheel::ReadWrite object exceeds a certain\nsize (the \"high water\" mark, or HighMark). This advises an application to stop streaming output.\nPOE and Perl really don't care if the application continues, but it's possible that the process\nmay run out of memory if a buffer grows without bounds.\n\nA POE::Wheel::ReadWrite object will continue to flush its buffer even after an application stops\nstreaming data, until the buffer is empty. Some streaming applications may require the buffer to\nalways be primed with data, however. For example, a media server would encounter stutters if it\nwaited for a FlushedEvent before sending more data.\n\nLowEvent solves the stutter problem. A POE::Wheel::ReadWrite object will send a LowEvent when\nits output buffer drains below a certain level (the \"low water\" mark, or LowMark). This notifies\nan application that the buffer is small enough that it may resume streaming.\n\nThe stutter problem is solved because the output buffer never quite reaches empty.\n\nHighEvent and LowEvent are edge-triggered, not level-triggered. This means they are emitted once\nwhenever a POE::Wheel::ReadWrite object's output buffer crosses the HighMark or LowMark. If an\napplication continues to put() data after the HighMark is reached, it will not cause another\nHighEvent to be sent.\n\nHighEvent is generally not needed. The put() method will return the high watermark state: true\nif the buffer is at or above the high watermark, or false if the buffer has room for more data.\nHere's a quick way to prime a POE::Wheel::ReadWrite object's output buffer:\n\n1 while not $[HEAP]{readwrite}->put(getnextdata());\n\nPOE::Wheel::ReadWrite objects always start in a low-water state.\n\nHighEvent and LowEvent are optional. Omit them if flow control is not needed.\n\nLowEvent\nHighEvent and LowEvent are used along with HighMark and LowMark to control the flow of streamed\noutput. Please see \"HighEvent\" for more information and examples.\n\nput RECORDS" }, { "name": "put", "content": "written by its Driver.\n" }, { "name": "put", "content": "exceeded the limit. False is returned if HighMark has not been set, or if the Driver's buffer is\nsmaller than that limit.\n" }, { "name": "put", "content": "HighMark---at the risk of exceeding the process' memory limits. Do not use \"<1 while not\n$wheel-\"put()>> syntax if HighMark isn't set: the application will fail spectacularly!\n\nevent EVENTTYPE => EVENTNAME, ..." }, { "name": "event", "content": "All constructor parameters ending in \"Event\" may be changed at run time: \"InputEvent\",\n\"FlushedEvent\", \"ErrorEvent\", \"HighEvent\", and \"LowEvent\".\n\nSetting an event to undef will disable the code within the wheel that generates the event. So\nfor example, stopping InputEvent will also stop reading from the filehandle. \"pauseinput\" and\n\"resumeinput\" may be a better way to manage input events, however.\n\nsetfilter POEFILTER" }, { "name": "set_filter", "content": "Any pending data that has not been dispatched to the application will be parsed with the new\nPOEFILTER. Information that has been put() but not flushed will not be reserialized.\n" }, { "name": "set_filter", "content": "the same POE::Filter object.\n\nSwitching filters can be tricky. Please see the discussion of getpending() in POE::Filter. Some\nfilters may not support being dynamically loaded or unloaded.\n\nsetinputfilter POEFILTER" }, { "name": "set_input_filter", "content": "output filter unchanged. This alters the way data is parsed without affecting how it's\nserialized for output.\n\nsetoutputfilter POEFILTER" }, { "name": "set_output_filter", "content": "not affect the way data is parsed.\n\ngetinputfilter" }, { "name": "get_input_filter", "content": "object to parse incoming data. The returned object may be introspected or altered via its own\nmethods.\n\nThere is no getfilter() method because there is no sane return value when input and output\nfilters differ.\n\ngetoutputfilter" }, { "name": "get_output_filter", "content": "object to serialize outgoing data. The returned object may be introspected or altered via its\nown methods.\n\nThere is no getfilter() method because there is no sane return value when input and output\nfilters differ.\n\nsethighmark HIGHMARKOCTETS\nSets the high water mark---the number of octets that designates a \"full enough\" output buffer. A\nPOE::Wheel::ReadWrite object will emit a HighEvent when its output buffer expands to reach this\npoint. All put() calls will return true when the output buffer is equal or greater than\nHIGHMARKOCTETS.\n\nBoth HighEvent and put() indicate that it's unsafe to continue writing when the output buffer\nexpands to at least HIGHMARKOCTETS.\n\nsetlowmark LOWMARKOCTETS\nSets the low water mark---the number of octets that designates an \"empty enough\" output buffer.\nThis event lets an application know that it's safe to resume writing again.\n\nPOE::Wheel::ReadWrite objects will emit a LowEvent when their output buffers shrink to\nLOWMARKOCTETS after having reached HIGHMARKOCTETS.\n\nID\nID() returns a POE::Wheel::ReadWrite object's unique ID. ID() is usually called after the object\nis created so that the object may be stashed by its ID. Events generated by the\nPOE::Wheel::ReadWrite object will include the ID of the object, so that they may be matched back\nto their sources.\n\npauseinput" }, { "name": "pause_input", "content": "emitting InputEvent events. It's much more efficient than destroying the object outright,\nespecially if an application intends to resumeinput() later.\n\nresumeinput" }, { "name": "resume_input", "content": "watching for input, and thus resume sending InputEvent events. pauseinput() and resumeinput()\nimplement a form of input flow control, driven by the application itself.\n\ngetinputhandle" }, { "name": "get_input_handle", "content": "Manipulating filehandles that are managed by POE may cause nasty side effects, which may change\nfrom one POE release to the next. Please use caution.\n\ngetoutputhandle" }, { "name": "get_output_handle", "content": "Manipulating filehandles that are managed by POE may cause nasty side effects, which may change\nfrom one POE release to the next. Please use caution.\n\nshutdowninput\nCall shutdown($fh,0) on a POE::Wheel::ReadWrite object's input filehandle. This only works for\nsockets; nothing will happen for other types of filehandle.\n\nOccasionally, the POE::Wheel::ReadWrite object will stop monitoring its input filehandle for new\ndata. This occurs regardless of the filehandle type.\n\nshutdownoutput\nCall shutdown($fh,1) on a POE::Wheel::ReadWrite object's output filehandle. This only works for\nsockets; nothing will happen for other types of filehandle.\n\nOccasionally, the POE::Wheel::ReadWrite object will stop monitoring its output filehandle for\nnew data. This occurs regardless of the filehandle type.\n\ngetdriveroutoctets\nPOE::Driver objects contain output buffers that are flushed asynchronously." }, { "name": "get_driver_out_octets", "content": "buffer.\n\ngetdriveroutmessages\nPOE::Driver objects' output buffers may be message based. Every put() call may be buffered\nindividually. getdriveroutmessages() will return the number of pending put() messages that\nremain to be sent.\n\nStream-based drivers will simply return 1 if any data remains to be flushed. This is because\nthey operate with one potentially large message.\n\nflush" }, { "name": "flush", "content": "to flush small messages. Note, however, that complete flushing is not guaranteed---to do so\nwould mean potentially blocking indefinitely, which is undesirable in most POE applications.\n\nIf an application must guarantee a full buffer flush, it may loop flush() calls:\n\n$wheel->flush() while $wheel->getdriveroutoctets();\n\nHowever it would be prudent to check for errors as well. A flush() failure may be permanent, and\nan infinite loop is probably not what most developers have in mind here.\n\nIt should be obvious by now that this method is experimental. Its behavior may change or it may\ndisappear outright. Please let us know whether it's useful.\n" } ] }, "SEE ALSO": { "content": "POE::Wheel describes wheels in general.\n\nThe SEE ALSO section in POE contains a table of contents covering the entire POE distribution.\n", "subsections": [] }, "BUGS": { "content": "None known.\n\nAUTHORS & COPYRIGHTS\nPlease see POE for more information about authors and contributors.\n", "subsections": [] } } } }