view release on metacpan or  search on metacpan

lib/POE/Request.pm  view on Meta::CPAN

Explicitly cancel a request.  It's intended for use by the invoked
stage, since the caller is free to destroy its request at any time.
The callee doesn't have that ability, so cancel() grants it
explicitly.

A canceled request cannot generate a response.  If you are tempted to
precede cancel() with emit(), then use return() instead.  The return()
method is essentially an emit() followed by a cancel().

As mentioned earlier, canceling a request frees up the data associated
with that request.  Cancellation and destruction cascade through the
data associated with a request and any sub-stages and sub-requests.
This efficiently and automatically releases all resources associated
with the entire request tree rooted with the canceled request.

For example:

	App creates a request for an http client.
		HTTP client creates a request for a socket.
			Socket factory creates a request for a DNS resolver.

At any point in the hierarchy, a cancellation clears its context and
cancels the lower-level requests.  For example, if the App cancels the
HTTP request, the cancelation cascades to the socket factory, and then
to the DNS resolver.

This happens because of one recursive rule:  When a request is
canceled, the data members on both sides of the transaction are
destroyed.  This only works when stages consistently store subrequests
within their own requests.  Here the socket factory request is stored
in the main HTTP fetch request.  If the HTTP fetch is canceled before
the socket factory can create a connection, then the socket factory's
request is also canceled.

lib/POE/Watcher.pm  view on Meta::CPAN

hoisted into this class once patterns emerge in the subclasses.

POE::Watcher classes encapsulate POE::Kernel's event watchers.  They
allocate POE::Kernel watchers at creation time, and they release them
during destruction.  It is therefore important to keep references to
POE::Watcher objects until they are no longer needed.

The best place to store POE::Watcher objects is probably the current
stage's request closure.  Should the request be canceled for some
reason, its closure will be destroyed, and so will all the watchers
stored within it.  Use of this convention automates automatic cascaded
cleanup when a request is canceled.

=head2 new HASHREF

Create a new POE::Watcher.  Calls init() on the subclass to do the
actual constructing.

=cut

sub new {