I've run into a situation where POE::NFAs posting of state transitions into POEs event queue has become an issue. My machine processes a string of events and the output of the machine is completely dependant upon the type and order of previous events. As such, when an event causes a state change, I expect the change to happen immediately, because of and regardless of any not-yet-dispatched events in the event queue.
The crux of my issue is that due to NFAs non-immediate state transitions, the output of the machine is vastly different depending on whether or not the event queue contains any events at any point during its operation. While there are certainly ways to mitigate or eliminate the queuing of the next event to be processed until after the state change has been posted, this is not desirable nor always possible.
In my readings, I stumbled across a thread [ http://code.activestate.com/lists/perl-poe/29/ ] from over a decade[!] ago regarding this same issue. From my understanding, the core issue has not been completely resolved. I have implemented an 'immediate' option for POE::NFA that, when enabled, causes state changes to be sent with 'call' rather than with 'post', which resolves the aforementioned issue. I am hardly partial to my commits, but I would certainly appreciate further discussion on this topic.
Added 'immediate' option for changing states immediately. [call rathe…
…r than post]
Added a bit of documentation about the new immediate option as well a…
…s how POE::NFA operates by default.
Moved documentation change to a less illogical spot.
Thank you for the pull request. If it passes 'make test', I'll ship it.
I'm a bit more relaxed than I was a decade ago. I like that it's an option, and I like that the default behavior maintains compatibility. It would have been a little nicer to combine commits ffbd225 and 71b1647 before sending the pull request, but I'm not going to be a jerk and reject your pull request for that.