NAME¶
"IO::Async::Notifier" - base class for "IO::Async" event
objects
SYNOPSIS¶
Usually not directly used by a program, but one valid use case may be:
use IO::Async::Notifier;
use IO::Async::Stream;
use IO::Async::Signal;
use IO::Async::Loop;
my $loop = IO::Async::Loop->new;
my $notifier = IO::Async::Notifier->new;
$notifier->add_child(
IO::Async::Stream->new_for_stdin(
on_read => sub {
my $self = shift;
my ( $buffref, $eof ) = @_;
while( $$buffref =~ s/^(.*)\n// ) {
print "You said $1\n";
}
return 0;
},
)
);
$notifier->add_child(
IO::Async::Signal->new(
name => 'INT',
on_receipt => sub {
print "Goodbye!\n";
$loop->stop;
},
)
);
$loop->add( $notifier );
$loop->run;
DESCRIPTION¶
This object class forms the basis for all the other event objects that an
"IO::Async" program uses. It provides the lowest level of
integration with a "IO::Async::Loop" container, and a facility to
collect Notifiers together, in a tree structure, where any Notifier can
contain a collection of children.
Normally, objects in this class would not be directly used by an end program, as
it performs no actual IO work, and generates no actual events. These are all
left to the various subclasses, such as:
- •
- IO::Async::Handle - event callbacks for a non-blocking file
descriptor
- •
- IO::Async::Stream - event callbacks and write bufering for a stream
filehandle
- •
- IO::Async::Socket - event callbacks and send buffering for a socket
filehandle
- •
- IO::Async::Timer - base class for Notifiers that use timed delays
- •
- IO::Async::Signal - event callback on receipt of a POSIX signal
- •
- IO::Async::PID - event callback on exit of a child process
- •
- IO::Async::Process - start and manage a child process
For more detail, see the SYNOPSIS section in one of the above.
One case where this object class would be used, is when a library wishes to
provide a sub-component which consists of multiple other "Notifier"
subclasses, such as "Handle"s and "Timers", but no
particular object is suitable to be the root of a tree. In this case, a plain
"Notifier" object can be used as the tree root, and all the other
notifiers added as children of it.
AS A MIXIN¶
Rather than being used as a subclass this package also supports being used as a
non-principle superclass for an object, as a mix-in. It still provides methods
and satisfies an "isa" test, even though the constructor is not
directly called. This simply requires that the object be based on a normal
blessed hash reference and include "IO::Async::Notifier" somewhere
in its @ISA list.
The methods in this class all use only keys in the hash prefixed by
"IO_Async_Notifier__" for namespace purposes.
This is intended mainly for defining a subclass of some other object that is
also an "IO::Async::Notifier", suitable to be added to an
"IO::Async::Loop".
package SomeEventSource::Async;
use base qw( SomeEventSource IO::Async::Notifier );
sub _add_to_loop
{
my $self = shift;
my ( $loop ) = @_;
# Code here to set up event handling on $loop that may be required
}
sub _remove_from_loop
{
my $self = shift;
my ( $loop ) = @_;
# Code here to undo the event handling set up above
}
Since all the methods documented here will be available, the implementation may
wish to use the "configure" and "make_event_cb" or
"invoke_event" methods to implement its own event callbacks.
EVENTS¶
The following events are invoked, either using subclass methods or CODE
references in parameters:
on_error $message, $name, @details¶
Invoked by "invoke_error".
PARAMETERS¶
A specific subclass of "IO::Async::Notifier" defines named parameters
that control its behaviour. These may be passed to the "new"
constructor, or to the "configure" method. The documentation on each
specific subclass will give details on the parameters that exist, and their
uses. Some parameters may only support being set once at construction time, or
only support being changed if the object is in a particular state.
The following parameters are supported by all Notifiers:
- on_error => CODE
- CODE reference for event handler.
- notifier_name => STRING
- Optional string used to identify this particular Notifier. This value will
be returned by the "notifier_name" method.
CONSTRUCTOR¶
$notifier = IO::Async::Notifier->new( %params )¶
This function returns a new instance of a "IO::Async::Notifier" object
with the given initial values of the named parameters.
Up until "IO::Async" version 0.19, this module used to implement the
IO handle features now found in the "IO::Async::Handle" subclass.
Code that needs to use any of "handle", "read_handle",
"write_handle", "on_read_ready" or
"on_write_ready" should use IO::Async::Handle instead.
METHODS¶
Adjust the named parameters of the "Notifier" as given by the %params
hash.
$loop = $notifier->loop¶
Returns the "IO::Async::Loop" that this Notifier is a member of.
$name = $notifier->notifier_name¶
Returns the name to identify this Notifier. If a has not been set, it will
return the empty string. Subclasses may wish to override this behaviour to
return some more useful information, perhaps from configured parameters.
$f = $notifier->adopt_future( $f )¶
Stores a reference to the Future instance within the notifier itself, so the
reference doesn't get lost. This reference will be dropped when the future
becomes ready (either by success or failure). Additionally, if the future
failed the notifier's "invoke_error" method will be informed.
This means that if the notifier does not provide an "on_error"
handler, nor is there one anywhere in the parent chain, this will be fatal to
the caller of "$f->fail". To avoid this being fatal if the
failure is handled elsewhere, use the "else_done" method on the
future to obtain a sequence one that never fails.
$notifier->adopt_future( $f->else_done() )
The future itself is returned.
CHILD NOTIFIERS¶
During the execution of a program, it may be the case that certain IO handles
cause other handles to be created; for example, new sockets that have been
"accept()"ed from a listening socket. To facilitate these, a
notifier may contain child notifier objects, that are automatically added to
or removed from the "IO::Async::Loop" that manages their parent.
$parent = $notifier->parent¶
Returns the parent of the notifier, or "undef" if does not have one.
@children = $notifier->children¶
Returns a list of the child notifiers contained within this one.
$notifier->add_child( $child )¶
Adds a child notifier. This notifier will be added to the containing loop, if
the parent has one. Only a notifier that does not currently have a parent and
is not currently a member of any loop may be added as a child. If the child
itself has grandchildren, these will be recursively added to the containing
loop.
$notifier->remove_child( $child )¶
Removes a child notifier. The child will be removed from the containing loop, if
the parent has one. If the child itself has grandchildren, these will be
recurively removed from the loop.
$notifier->remove_from_parent¶
Removes this notifier object from its parent (either another notifier object or
the containing loop) if it has one. If the notifier is not a child of another
notifier nor a member of a loop, this method does nothing.
SUBCLASS METHODS¶
"IO::Async::Notifier" is a base class provided so that specific
subclasses of it provide more specific behaviour. The base class provides a
number of methods that subclasses may wish to override.
If a subclass implements any of these, be sure to invoke the superclass method
at some point within the code.
$notifier->_init( $paramsref )¶
This method is called by the constructor just before calling
"configure". It is passed a reference to the HASH storing the
constructor arguments.
This method may initialise internal details of the Notifier as required,
possibly by using parameters from the HASH. If any parameters are
construction-only they should be "delete"d from the hash.
This method is called by the constructor to set the initial values of named
parameters, and by users of the object to adjust the values once constructed.
This method should "delete" from the %params hash any keys it has
dealt with, then pass the remaining ones to the "SUPER::configure".
The base class implementation will throw an exception if there are any
unrecognised keys remaining.
This method is called by the base class "configure" method, for any
remaining parameters that are not recognised. The default implementation
throws an exception using "Carp" that lists the unrecognised keys.
This method is provided to allow subclasses to override the behaviour, perhaps
to store unrecognised keys, or to otherwise inspect the left-over arguments
for some other purpose.
$notifier->_add_to_loop( $loop )¶
This method is called when the Notifier has been added to a Loop; either
directly, or indirectly through being a child of a Notifer already in a loop.
This method may be used to perform any initial startup activity required for the
Notifier to be fully functional but which requires a Loop to do so.
$notifier->_remove_from_loop( $loop )¶
This method is called when the Notifier has been removed from a Loop; either
directly, or indirectly through being a child of a Notifier removed from the
loop.
This method may be used to undo the effects of any setup that the
"_add_to_loop" method had originally done.
UTILITY METHODS¶
$mref = $notifier->_capture_weakself( $code )¶
Returns a new CODE ref which, when invoked, will invoke the originally-passed
ref, with additionally a reference to the Notifier as its first argument. The
Notifier reference is stored weakly in $mref, so this CODE ref may be stored
in the Notifier itself without creating a cycle.
For example,
my $mref = $notifier->_capture_weakself( sub {
my ( $notifier, $arg ) = @_;
print "Notifier $notifier got argument $arg\n";
} );
$mref->( 123 );
This is provided as a utility for Notifier subclasses to use to build a callback
CODEref to pass to a Loop method, but which may also want to store the CODE
ref internally for efficiency.
The $code argument may also be a plain string, which will be used as a method
name; the returned CODE ref will then invoke that method on the object. In
this case the method name is stored symbolically in the returned CODE
reference, and dynamically dispatched each time the reference is invoked. This
allows it to follow code reloading, dynamic replacement of class methods, or
other similar techniques.
If the $mref CODE reference is being stored in some object other than the one it
refers to, remember that since the Notifier is only weakly captured, it is
possible that it has been destroyed by the time the code runs, and so the
reference will be passed as "undef". This should be protected
against by the code body.
$other_object->{on_event} = $notifier->_capture_weakself( sub {
my $notifier = shift or return;
my ( @event_args ) = @_;
...
} );
For stand-alone generic implementation of this behaviour, see also curry and
"curry::weak".
$mref = $notifier->_replace_weakself( $code )¶
Returns a new CODE ref which, when invoked, will invoke the originally-passed
ref, with a reference to the Notifier replacing its first argument. The
Notifier reference is stored weakly in $mref, so this CODE ref may be stored
in the Notifier itself without creating a cycle.
For example,
my $mref = $notifier->_replace_weakself( sub {
my ( $notifier, $arg ) = @_;
print "Notifier $notifier got argument $arg\n";
} );
$mref->( $object, 123 );
This is provided as a utility for Notifier subclasses to use for event callbacks
on other objects, where the delegated object is passed in the function's
arguments.
The $code argument may also be a plain string, which will be used as a method
name; the returned CODE ref will then invoke that method on the object. As
with "_capture_weakself" this is stored symbolically.
As with "_capture_weakself", care should be taken against Notifier
destruction if the $mref CODE reference is stored in some other object.
$code = $notifier->can_event( $event_name )¶
Returns a "CODE" reference if the object can perform the given event
name, either by a configured "CODE" reference parameter, or by
implementing a method. If the object is unable to handle this event,
"undef" is returned.
$callback = $notifier->make_event_cb( $event_name )¶
Returns a "CODE" reference which, when invoked, will execute the given
event handler. Event handlers may either be subclass methods, or parameters
given to the "new" or "configure" method.
The event handler can be passed extra arguments by giving them to the
"CODE" reference; the first parameter received will be a reference
to the notifier itself. This is stored weakly in the closure, so it is safe to
store the resulting "CODE" reference in the object itself without
causing a reference cycle.
$callback = $notifier->maybe_make_event_cb( $event_name )¶
Similar to "make_event_cb" but will return "undef" if the
object cannot handle the named event, rather than throwing an exception.
@ret = $notifier->invoke_event( $event_name, @args )¶
Invokes the given event handler, passing in the given arguments. Event handlers
may either be subclass methods, or parameters given to the "new" or
"configure" method. Returns whatever the underlying method or CODE
reference returned.
$retref = $notifier->maybe_invoke_event( $event_name, @args )¶
Similar to "invoke_event" but will return "undef" if the
object cannot handle the name event, rather than throwing an exception. In
order to distinguish this from an event-handling function that simply returned
"undef", if the object does handle the event, the list that it
returns will be returned in an ARRAY reference.
DEBUGGING SUPPORT¶
The following methods and behaviours are still experimental and may change or
even be removed in future.
Debugging support is enabled by an environment variable called
"IO_ASYNC_DEBUG" having a true value.
When debugging is enabled, the "make_event_cb" and
"invoke_event" methods (and their "maybe_" variants) are
altered such that when the event is fired, a debugging line is printed, using
the "debug_printf" method. This identifes the name of the event.
By default, the line is only printed if the caller of one of these methods is
the same package as the object is blessed into, allowing it to print the
events of the most-derived class, without the extra verbosity of the
lower-level events of its parent class used to create it. All calls regardless
of caller can be printed by setting a number greater than 1 as the value of
"IO_ASYNC_DEBUG".
By default the debugging log goes to "STDERR", but two other
environment variables can redirect it. If "IO_ASYNC_DEBUG_FILE" is
set, it names a file which will be opened for writing, and logging written
into it. Otherwise, if "IO_ASYNC_DEBUG_FD" is set, it gives a file
descriptor number that logging should be written to. If opening the named file
or file descriptor fails then the log will be written to "STDERR" as
normal.
Conditionally print a debugging message to "STDERR" if debugging is
enabled. If such a message is printed, it will be printed using
"printf" using the given format and arguments. The message will be
prefixed with an string, in square brackets, to help identify the $notifier
instance. This string will be the class name of the notifier, and any parent
notifiers it is contained by, joined by an arrow "<-". To ensure
this string does not grow too long, certain prefixes are abbreviated:
IO::Async::Protocol:: => IaP:
IO::Async:: => Ia:
Net::Async:: => Na:
Finally, each notifier that has a name defined using the
"notifier_name" parameter has that name appended in braces.
For example, invoking
$stream->debug_printf( "EVENT on_read" )
On an "IO::Async::Stream" instance reading and writing a file
descriptor whose "fileno" is 4, which is a child of an
"IO::Async::Protocol::Stream", will produce a line of output:
[Ia:Stream{rw=4}<-IaP:Stream] EVENT on_read
$notifier->invoke_error( $message, $name, @details )¶
Invokes the stored "on_error" event handler, passing in the given
arguments. If no handler is defined, it will be passed up to the containing
parent notifier, if one exists. If no parent exists, the error message will be
thrown as an exception by using "die()" and this method will not
return.
If a handler is found to handle this error, the method will return as normal.
However, as the expected use-case is to handle "fatal" errors that
now render the notifier unsuitable to continue, code should be careful not to
perform any further work after invoking it. Specifically, sockets may become
disconnected, or the entire notifier may now be removed from its containing
loop.
The $name and @details list should follow similar semantics to Future failures.
That is, the $name should be a string giving a category of failure, and the
@details list should contain additional arguments that relate to that kind of
failure.
AUTHOR¶
Paul Evans <leonerd@leonerd.org.uk>