PatchReader is a set of utilities for reading in, transforming, and doing
various other things with a patch. It basically allows you to create a chain of
readers that can read a patch, remove files from a patch, add CVS context, fix
up the patch root according to CVS, and output the patch as raw unified or
through a template processor (used in some places to output a patch as HTML).
If you need nonblocking access to an external program, or want to execute some
blocking code in a separate process, but you don't want to write a wrapper
module or some POE::Wheel::Run boilerplate code, then POE::Quickie can help.
You just specify what you're interested in (stdout, stderr, and/or exit code),
and POE::Quickie will handle the rest in a sensible way.
It has some convenience features, such as killing processes after a timeout,
and storing process-specific context information which will be delivered with
every event.
There is also an even lazier API which suspends the execution of your event
handler and gives control back to POE while your task is running, the same
way LWP::UserAgent::POE does.
This is provided by the quickie_* functions which are exported by default.
POE::Session::MultiDispatch is a drop in replacement for POE::Session
that adds callback dispatch functionality to POE sessions. Each event
may have multiple handlers associated with it. Fine control over the
order of execution is available using helper methods that extend the
interface of a POE::Session.
POE::Session::MultiDispatch uses POE::Session as a base class. When
multiple callbacks are registered for an event, only the last callback
survives, all the others are clobbered. POE::Session::MultiDispatch is
much nicer to your registered callbacks, it keeps them all in the order
they were defined. When an event is triggered, all the callbacks are
then executed in that same order (unless you muck around with said
order).
POE::Stage is a proposed base class for POE components. Its purpose is
to standardize the most common design patterns that have arisen through
years of POE::Component development.
POE::Test::Loops contains one function, generate(), which will
generate all the loop tests for one or more POE::Loop subclasses.
Implementation of the abstract POE::Loop interface written in C
using the poll(2) system call.
This class is an implementation of the abstract POE::Queue interface.
It implements a priority queue using C, with an XS interface supplied.
POE is a general purpose multitasking and networking framework.
POE does standard event loop things, cooperative multitasking, network
clients and servers; includes a high level class library that takes care
of event driven I/O; provides a framework for portable program components.
POEx::Role::SessionInstantiation provides a nearly seamless
integration for non-POE objects into a POE environment. It does this
by handling the POE stuff behind the scenes including allowing per
instances method changes, session registration to the Kernel, and
providing some defaults like setting an alias if supplied via the
attribute or constructor argument, or defining a _default that warns
if your object receives an event that it does not have.
This role exposes your class' methods as POE events.
POEx::Role::Streaming provides a common idiom for streaming data from
one filehandle to another. It accomplishes this by making good use of
sysread and POE::Wheel::ReadWrite. This Role errs on the side of
doing as many blocking reads of the "input_handle" as possible up
front (until the high water mark is hit on the Wheel). If this
default isn't suitable for the consumer, simply override
"get_data_from_input_handle". After Streamer has exhausted the
source, and flushed the last of the output, it will clean up after
itself by closing the wheel, the handles, and sending all of them out
of scope. If an exception happens, it will clean up after itself, and
let the DIE signal propagate.