Provided by: libpoe-perl_1.3670-2_all bug


       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.
           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");


         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) {
           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 run time, so they aren't really
       "finite".  Run-time 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 run-time

       But more simply, POE::NFA is like POE::Session but with banks of event handlers that may
       be swapped according to the session's run-time state.  Consider the SYNOPSIS example,
       which has "on_entry" and "on_input" handlers that do different things depending on the
       run-time 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;

       Instead of "inline_states", "object_states" or "package_states" may be used. These map the
       events of a state to an object or package method respectively.

         object_states => {
           state_1 => [
             $object_1 => [qw(event_1 event_2)],
           state_2 => [
             $object_2 => {
               event_1 => method_1,
               event_2 => method_2,

       In the example above, in the case of "event_1" coming in while the machine is in
       "state_1", method "event_1" will be called on $object_1. If the machine is in "state_2",
       method "method_1" will be called on $object_2.

       "package_states" is very similar, but instead of using an $object, you pass in a

       The "runstate" parameter allows "RUNSTATE" to be initialized differently at instantiation
       time. "RUNSTATE", like heaps, are usually anonymous hashrefs, but "runstate" may set them
       to be array references or even objects.

       State transitions are not necessarily executed immediately by default.  Rather, they are
       placed in POEs event queue behind any currently pending events.  Enabling the "immediate"
       option causes state transitions to occur immediately, regardless of any queued events.

       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


       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

   return_state [RETURN_ARGS]
       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

         $_[MACHINE]->return_state( 'success', @success_values );

   Methods that match POE::Session
       The following methods behave identically to the ones in POE::Session.


   About new() and create()
       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

       "MACHINE" is equivalent to Session's "SESSION" field.  It holds a reference to the current
       state machine, and is 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",

       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


       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


       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.