Hi, I'm implementing an asynchronous state machine and have problems with events not being dispatched. All event thrown at the fsm are dispatched to the unhandled_event method. When debugging the problem, I used typeid on the event to see that the expected events were generated (they were) from the event dispatch threads. After this, I tried to get the current state from within the unhandled_event() method - but to my surprise the statement "this->state_begin() != this->state_end()" is never satisfied. Looks like there's no current state. What's even more confusing is that this behaviour is only exposed in the application itself. This part of the project is divided into three modules; the application, a static library containing most of the code, and a unit test driver. The test driver and the application links to the library. When running the unit tests, the dispatching works and it is possible to see the current state using the above method. Release or debug mode doesn't matter. RTTI is enabled. Using RC_1_34_0 and VC8. What could possibly expose this behaviour? // Johan
Johan Nilsson wrote:
Hi,
I'm implementing an asynchronous state machine and have problems with events not being dispatched. All event thrown at the fsm are dispatched to the unhandled_event method.
When debugging the problem, I used typeid on the event to see that the expected events were generated (they were) from the event dispatch threads. After this, I tried to get the current state from within the unhandled_event() method - but to my surprise the statement "this->state_begin() != this->state_end()" is never satisfied. Looks like there's no current state.
Well, isn't it weird that as soon as one asks for help, you find the problem yourself. I'd just forgot the call to fifo_scheduler<>::initiate_processor in the application. Doh! Would it be possible to check if the processor has been initiated when calling "scheduler::operator()"? I don't think it would be a huge overhead as this operator is called quite infrequently (only once per app invocation in my case). At least, adding an assertion in debug builds would be of great help. Andreas? Thanks // Johan
Johan Nilsson wrote: [snip]
Well, isn't it weird that as soon as one asks for help, you find the problem yourself.
I'd just forgot the call to fifo_scheduler<>::initiate_processor in the application. Doh!
Would it be possible to check if the processor has been initiated when calling "scheduler::operator()"?
The current interface allows you to create and initiate processors before or after scheduler::operator() has been called. Sometimes you even need to call create_processor() before and initiate_processor() afterwards. Sometimes you also want to reuse a state_machine that has terminated and therefore need to call initiate_processor() again. Therefore, if scheduler::operator() asserts that all created processors have also been initiated then this would preclude some legitimate real-world use cases and would also not catch the cases where a FSM has terminated after being initiated. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
Andreas Huber wrote:
Johan Nilsson wrote: [snip]
Well, isn't it weird that as soon as one asks for help, you find the problem yourself.
I'd just forgot the call to fifo_scheduler<>::initiate_processor in the application. Doh!
Would it be possible to check if the processor has been initiated when calling "scheduler::operator()"?
The current interface allows you to create and initiate processors before or after scheduler::operator() has been called. Sometimes you even need to call create_processor() before and initiate_processor() afterwards.
Out of curiosity, why would one ever want to call scheduler::operator() before initiate_processor()? // Johan
Johan Nilsson wrote:
The current interface allows you to create and initiate processors before or after scheduler::operator() has been called. Sometimes you even need to call create_processor() before and initiate_processor() afterwards.
Out of curiosity, why would one ever want to call scheduler::operator() before initiate_processor()?
This happens quite often. On system start-up you simply start a new scheduler in its own thread, without creating any processors beforehand. Processors are later created on demand, depending on external input. I've never worked in the telephony field but I could imagine that you might want to create a new FSM when a call is placed and destroy it later when the call ends. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
participants (2)
-
Andreas Huber -
Johan Nilsson