Talk:Event-driven finite-state machine

message: I removed the following from the article, as it appears to be unencyclopeadic, and/or confusing or strange:
:The author of StateCHARTS uses the term event driven finite state machine to describe machines where any incoming input has to be consumed immediately, i.e. the FSM has to perform a transition or input action otherwise the input disappears.
:In contrast to the StateCHART virtual finite state machine (VFSM) technology, the application of event driven FSM in complex systems leads to the state explosion problem, as each truly required state path must be repeated for all possible input values. Event driven FSM can be implemented with a state transition table as is often done for parser applications.
:A significant reduction in complexity can be achieved by utilizing hierarchy a la hierarchical state machines (HSMs).  The use of hierarchy eliminates the "state explosion" problem by allowing a single transition from multiple related states, through state nesting.  A more rigorous definition of hierarchical state machines that includes an example can be found at http://www.quantum-leaps.com/resources/glossary.htm#HSM.
:Possibly cite http://www.programmersheaven.com/2/Design-State-Machine-Engine (an example of someone speaking about event-driven state machines as an informal idiom)
Please don't re-insert without review. linas 21:40, 29 May 2007 (UTC)
thread_title: Removed text

message: There's a bug in this program as state_init == state_red, but there's separate STATE_INIT and STATE_RED states, so red will initially be on for 60 secs, not 30. Genjix (talk) 03:24, 17 March 2008 (UTC)
thread_title: Bug in program

message: The variable 'operation' is set to 1 at the beginning of the program, and never changed afterwards.  Hard to see what the point is.  — Preceding unsigned comment added by Davep88 (talk • contribs) 05:42, 24 June 2011 (UTC)
thread_title: Possible bug in program

message: Why isn't there any discussion of why state machines could be a bad idea? This code could be a million times clearer if it was allowed to explicitly pend on events.  —Preceding unsigned comment added by 216.31.211.11 (talk) 00:03, 11 September 2008 (UTC)
replies: text: Because in places they're used, at any particular time the object must be able to respond to any one of several possible events which could happen. For instance, a traffic light that normally switches based on a timer could have an input that's switched by an emergency vehicle. This would alter the pattern to give the vehicle right of way when it is detected. The code can't be looping just looking at the timer when it needs to also respond to the emergency vehicle switch.--71.214.211.129 (talk) 17:02, 18 September 2010 (UTC)
thread_title: Controversiality

message: The text gives little information besides what one could figure out just from the term "event-driven finite-state machine" yeah, it's a machine that's event driven, big deal! What's are the benefits of event-driven, why should one use that? What's the caveats? What are events at all in programming context? The program listing itself is also hard to understand if you don't know C. What's  switch(state)m where does "state" come from, its a variable, right? You define STATES state = ST_RADIO; and then suddenly state is switched. Where does it get it's value? switch(event) is at least filled by the function readEventFromMessageQueue(), but what is EVENTS readEventFromMessageQueue(void); doing? Comment says: "Usually this is a blocking function." what is a blocking function? I know only little programming someone with less or none experience only sees gibberish. Wouldn't it be better, to have it in readable pseudocode? Also the text describes "often used in telecommunication protocols" and then gives an example of a - car radio? --95.91.240.250 (talk) 20:56, 21 October 2013 (UTC)
thread_title: Hard to understand