POE::NFA - an event-driven state machine (nondeterministic finite automaton)
use POE::Kernel;
use POE::NFA;
use POE::Wheel::ReadLine;
# Spawn an NFA and enter its initial state.
POE::NFA->spawn(
inline_states => {
initial => {
setup => \&setup_stuff,
},
state_login => {
on_entry => \&login_prompt,
on_input => \&save_login,
},
state_password => {
on_entry => \&password_prompt,
on_input => \&check_password,
},
state_cmd => {
on_entry => \&command_prompt,
on_input => \&handle_command,
},
},
)->goto_state(initial => "setup");
POE::Kernel->run();
exit;
sub setup_stuff {
$_[RUNSTATE]{io} = POE::Wheel::ReadLine->new(
InputEvent => 'on_input',
);
$_[MACHINE]->goto_state(state_login => "on_entry");
}
sub login_prompt { $_[RUNSTATE]{io}->get('Login: '); }
sub save_login {
$_[RUNSTATE]{login} = $_[ARG0];
$_[MACHINE]->goto_state(state_password => "on_entry");
}
sub password_prompt { $_[RUNSTATE]{io}->get('Password: '); }
sub check_password {
if ($_[RUNSTATE]{login} eq $_[ARG0]) {
$_[MACHINE]->goto_state(state_cmd => "on_entry");
}
else {
$_[MACHINE]->goto_state(state_login => "on_entry");
}
}
sub command_prompt { $_[RUNSTATE]{io}->get('Cmd: '); }
sub handle_command {
$_[RUNSTATE]{io}->put(" <<$_[ARG0]>>");
if ($_[ARG0] =~ /^(?:quit|stop|exit|halt|bye)$/i) {
$_[RUNSTATE]{io}->put('Bye!');
$_[MACHINE]->stop();
}
else {
$_[MACHINE]->goto_state(state_cmd => "on_entry");
}
}
POE::NFA implements a different kind of POE session: A non-deterministic finite automaton. Let's break that down.
A finite automaton is a state machine with a bounded number of states and transitions. Technically, POE::NFA objects may modify themselves at runtime, so they aren't really "finite". Runtime modification isn't currently supported by the API, so plausible deniability is maintained!
Deterministic state machines are ones where all possible transitions are known at compile time. POE::NFA is "non-deterministic" because transitions may change based on runtime conditions.
But more simply, POE::NFA is like POE::Session but with banks of event handlers that may be swapped according to the session's runtime state. Consider the SYNOPSIS example, which has "on_entry" and "on_input" handlers that do different things depending on the runtime state. POE::Wheel::ReadLine throws "on_input", but different things happen depending whether the session is in its "login", "password" or "command" state.
POE::NFA borrows heavily from POE::Session, so this document will only discuss the differences. Please see POE::Session for things which are similar.
This document mainly focuses on the differences from POE::Session.
Each machine state has a name. get_current_state() returns the name
of the machine's current state. get_current_state() is mainly used to
retrieve the state of some other machine. It's easier (and faster) to
use $_[STATE] in a machine's own event handlers.
get_runstate() returns the machine's current runstate. Runstates are
equivalent to POE::Session HEAPs, so this method does pretty much the
same as POE::Session's get_heap(). It's easier (and faster) to use
$_[RUNSTATE] in a machine's own event handlers, however.
spawn() is POE::NFA's constructor. The name reflects the idea that new state machines are spawned like threads or processes rather than instantiated like objects.
The machine itself is defined as a list of state names and hashes that map events to handlers within each state.
my %states = (
state_1 => {
event_1 => \&handler_1,
event_2 => \&handler_2,
},
state_2 => {
event_1 => \&handler_3,
event_2 => \&handler_4,
},
);
A single event may be handled by many states. The proper handler will
be called depending on the machine's current state. For example, if
event_1 is dispatched while the machine is in state_2, then
handler_3() will be called to handle the event. The state -> event ->
handler map looks like this:
$machine{state_2}{event_1} = \&handler_3;
The spawn() method currently only accepts inline_states and
options. Others may be added as necessary.
goto_state() puts the machine into a new state. If an ENTRY_EVENT is
specified, then that event will be dispatched after the machine enters
the new state. EVENT_ARGS, if included, will be passed to the entry
event's handler via ARG0..$#_.
# Switch to the next state. $_[MACHINE]->goto_state( 'next_state' ); # Switch to the next state, and call a specific entry point. $_[MACHINE]->goto_state( 'next_state', 'entry_event' ); # Switch to the next state; call an entry point with some values. $_[MACHINE]->goto_state( 'next_state', 'entry_event', @parameters );
stop() forces a machine to stop. The machine will also stop gracefully if it runs out of things to do, just like POE::Session.
stop() is heavy-handed. It will force resources to be cleaned up.
However, circular references in the machine's RUNSTATE are not
POE's responsibility and may cause memory leaks.
$_[MACHINE]->stop();
call_state() is similar to goto_state(), but it pushes the current
state on a stack. At some later point, a handler can call
return_state() to pop the call stack and return the machine to its old
state. At that point, a RETURN_EVENT will be posted to notify the
old state of the return.
$machine->call_state( 'return_here', 'new_state', 'entry_event' );
As with goto_state(), ENTRY_EVENT is the event that will be emitted
once the machine enters its new state. ENTRY_ARGS are parameters
passed to the ENTRY_EVENT handler via ARG0..$#_.
return_state() returns to the most recent state in which call_state()
was invoked. If the preceding call_state() included a return event
then its handler will be invoked along with some optional
RETURN_ARGS. The RETURN_ARGS will be passed to the return
handler via ARG0..$#_.
$_[MACHINE]->return_state( 'success', @success_values );
The following methods behave identically to the ones in POE::Session.
POE::NFA's constructor is spawn(), not new() or create().
POE::NFA's predefined event fields are the same as POE::Session's with the following three exceptions.
MACHINE is equivalent to Session's SESSION field. It hold a
reference to the current state machine, and it's useful for calling
its methods.
See POE::Session's SESSION field for more information.
$_[MACHINE]->goto_state( $next_state, $next_state_entry_event );
RUNSTATE is equivalent to Session's HEAP field. It holds an
anonymous hash reference which POE is guaranteed not to touch. Data
stored in RUNSTATE will persist between handler invocations.
STATE contains the name of the machine's current state. It is not
equivalent to anything from POE::Session.
EVENT is equivalent to Session's STATE field. It holds the name
of the event which invoked the current handler. See POE::Session's
STATE field for more information.
POE::NFA defines four events of its own. These events are used internally and may not be overridden by application code.
See POE::Session's "PREDEFINED EVENT NAMES" section for more information about other predefined events.
The events are: poe_nfa_goto_state, poe_nfa_push_state,
poe_nfa_pop_state, poe_nfa_stop.
Yes, all the internal events begin with "poe_nfa_". More may be forthcoming, but they will always begin the same way. Therefore please do not define events beginning with "poe_nfa_".
Many of POE::NFA's features are taken directly from POE::Session. Please see POE::Session for more information.
The SEE ALSO section in POE contains a table of contents covering the entire POE distribution.
See POE::Session's documentation.
POE::NFA is not as feature-complete as POE::Session. Your feedback is appreciated.
Please see POE for more information about authors and contributors.