Jurai, On Thu, Mar 29, 2012 at 7:07 PM, Juraj Ivančić wrote:

I know how you feel. MSM is an awesome library. Unfortunately compilers tend to disagree :)

Indeed. I am having massive trouble boost.binding the process_event() function, which I call from within a threaded pool like thingy. It was so bad, I had to macro wrapper functions around it. Not even the usual static_cast trick helped. But this is something I can live with, considering all the benefits.

MSM has two kinds of transition functions, actions and guards. What you are describing above is an action, and it is not designed to prevent the transition. You should use a guard. Guards have a boolean return value. For an example see good_disk_format() function in the SimpleTutorial.cpp in the MSM docs.

I know about this difference. But it doesn't cover what I mean. Exceptions as in 'exceptional situations'. Consider the socket example. You would probably like to use a MSM to implement a protocol. Not when you do a transition from let's say state 'Idle' to state 'Connected' you would be able to make sure everything is ready for connection in your guard. Like checking if you have your target endpoint and it is correct and whatever else you need. But still, your connect() that you would inevitably have to do in the transition may fail. Or anything else like that. In my implementation I have a lot of guards now checking whatever could go wrong but there's no way eliminating all possible exception courses. I have to assume process_event() will pass the exception to the caller and the transition will not occur but the docs are not specific about this. Plus since I called process event indirectly via Q and the wrapper will not know how to deal with this case. Let alone guarantee RAII in the transition. I believe it would be good to be able to bind an exception handler to each transition much like the guards, and to be able to return true or false from that handler, depending on what this function thinks if the exception should prevent transition or not. But this is only an idea. Cheers, Stephan

on Thu Mar 29 2012, "Christophe Henry" wrote:

...

Jurai,

On Thu, Mar 29, 2012 at 7:07 PM, Juraj Ivančić wrote:

...

I know how you feel. MSM is an awesome library. Unfortunately compilers tend to disagree :)

I'd say compilers should be blamed for this ;-) (I'm still wondering how it can be that compilers make such a poor use of my 6 cores with hyperthreading when compile a single object file...)

There isn't much inherent parallelism to exploit in C++ compilation of a single translation unit. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

On 01.04.2012, at 22:13, Christophe Henry wrote:

...

on Thu Mar 29 2012, "Christophe Henry" wrote:

...

...

Jurai,

On Thu, Mar 29, 2012 at 7:07 PM, Juraj Ivančić wrote:

...

I know how you feel. MSM is an awesome library. Unfortunately compilers tend to disagree :)

I'd say compilers should be blamed for this ;-) (I'm still wondering how it can be that compilers make such a poor use of my 6 cores with hyperthreading when compile a single object file...)

There isn't much inherent parallelism to exploit in C++ compilation of a single translation unit.

-- Dave Abrahams BoostPro Computing http://www.boostpro.com

I'm not an expert in this field, but this surprises me a bit. I understand that there is not much parallelism in parsing a file, but after? Taking msm as example. Most of the compile time comes from template instanciations of the function process_event for every event type. Adding support for a new event adds roughly the same compilation time. Every process_event has little in common with other process_event instances. What prevents the compiler from handling each at the same time?

The locking mechanism for ASTs would probably be very complicated if you want to do template instantiation in parallel. It probably could be done, but going that route isn't very attractive because the cores are much better used compiling 6 files in parallel. Sebastian

on Tue Apr 03 2012, Sebastian Redl wrote:

On 01.04.2012, at 22:13, Christophe Henry wrote:

...

I'm not an expert in this field, but this surprises me a bit. I understand that there is not much parallelism in parsing a file, but after? Taking msm as example. Most of the compile time comes from template instanciations of the function process_event for every event type. Adding support for a new event adds roughly the same compilation time. Every process_event has little in common with other process_event instances. What prevents the compiler from handling each at the same time?

The locking mechanism for ASTs would probably be very complicated if you want to do template instantiation in parallel. It probably could be done, but going that route isn't very attractive because the cores are much better used compiling 6 files in parallel.

Plus, the way the language is defined, ordering is very important. There's a point of definition and various points of instantiation... particular lookups are done in those locations, and the symbol table has to be right in each case, at least with respect to the symbols used in the template. I doubt it's easy to unwind those dependencies. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

on Thu Apr 05 2012, Steven Watanabe wrote:

AMDG

On 04/04/2012 06:07 PM, Dave Abrahams wrote:

...

Plus, the way the language is defined, ordering is very important. There's a point of definition and various points of instantiation... particular lookups are done in those locations, and the symbol table has to be right in each case, at least with respect to the symbols used in the template. I doubt it's easy to unwind those dependencies.

But...

"If the function name is an unqualified id and the call ... would find a better match had the lookup within the associated namespaces considered all the function declarations with external linkage introduced within those namespaces in all translation units, not just considering those declarations found in the template declaration and template instantiation contexts, then the program has undefined behavior." (14.6.4.2)

"If a template, a member template, or a member of a class template is explicitly specialized, then the specialization shall be declared before the first use of that specialization that would cause an implicit instantiation to take place... no diagnostic is required" (14.7.3) (There is a similar clause for partial specialization)

In other words, it seems to me that in most cases where delaying the point of instantiation would change the behavior it is either undefined behavior or ill-formed, no diagnostic required.

But "most cases" is not enough. If you can show that's true in *all* cases, there may be a case for parallel template instantiation. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

on Thu Mar 29 2012, "Christophe Henry" wrote:

...

If what you mean is generating an event from an asio handler, I usually use the following (simplified) solution (which I plan to add to a coming paper with msm + asio)

That sounds really cool! Please let us know when you publish!

-- Dave Abrahams BoostPro Computing http://www.boostpro.com

You can count on it! Christophe

Christophe, On Thu, Mar 29, 2012 at 9:46 PM, Christophe Henry wrote:

First of all, I have to give a word of caution. The UML Standard does not foresee exceptions and they don't mix well with the run-to-completion algorithm on which state machines rely. Try to avoid them if you can.

Yes, mum. ;-) I know, it's quite a pain and I have to deal with that quite often. Doing UML interface descriptions in common tools expose this particular problem all the time. In my opinion however, it is a problem the UML Standard has, not me. *duck*

Like the no_transition handler, you can overwrite it with your own. When this is called, the transition is interrupted where it was and ceases processing. This leaves you in a not very desirable state because you have been interrupted somewhere in the guard/exit/action/entry chain. When this happens, I advise you to process to yourself an error event to handle this gracefully. For example:

  template   void exception_caught (Event const&,FSM& fsm,std::exception& )   {       fsm.process_event(ErrorConnection());   }

Yes, that can work. I wasn't aware I can post events from within the state machine. But they are actually queued, as I see. Nice. It's getting even better. This should be able to deal with the problem. Only downside I can see is that I'd need an entry in the transition table for each state. I already had to adjust those MPL settings. But this will work, thanks.

You can prevent MSM from catching the exception by activating in your front end a switch:

typedef int no_exception_thrown;

Then, you get the exception thrown from your process_event call.

I think your first solution ist better because it allows me better to reset internal data to reasonable values.

In any case, the transition where the exception occurs is terminated and you don't need to terminate yourself.

OK, thanks. This should be explicitly stated like that in the tutorial. Or maybe it is and I just couldn't find it. Maybe there's room for one of those little chapters titled "exceptions". On a side note, there also could be room for a few words about how do I position such a thing in an existing (or new) architecture. Like best or common practice. When I started to work with it I was entirely unsure about it. I am here in a MVC arch with basically a GUI and a backend and threaded multiplexing controller (part of the GUI) -> backend functions and demultiplexing data signals -> GUI changes. As a first try, I understood the state machine as part of the controller logic belonging to one functionality and essentially one widget. Which meant that the SM was posting events to the backend functions in a threaded Q. This proved no good as the result of this was that a state could easily be switched without the backend having reacted yet, creating races and the possibility of acting twice. So I have moved it back behind the multiplexing, not posting async and so far I think I'm far better off. Another issue were interactions with other parts of the applications that send signals about, interfering with things the SM is now concerned with. Effectively creating need for far more reach the SM needs to have. Stuff like that. Christophe, if you are interested, I may be able to churn out a little article and about that if you are interested. Cheers, Stephan

  template   void exception_caught (Event const&,FSM& fsm,std::exception& )   {       fsm.process_event(ErrorConnection());   }

In a telecom application we are doing something similar, but we have several submachines, and we can have exceptions during the processing of the error event. In each submachnie we throw the exception further to the container machine. // Base template class for submachines template <typename T> class BaseStateMachine: public msm::front::state_machine_def<T> { public: // ... // Exception Handling template void exception_caught (Event const&,FSM& fsm,std::exception& e) { _DEBUG_LIB(&fsm.getLogger()," exception_caught "); boost::exception* be = dynamic_castboost::exception*(&e); if(be){ *be << EMsmEvent(removeNamespace<Event>()); throw; } else{ BOOST_THROW_EXCEPTION(MsmException() << EMsmEvent(removeNamespace<Event>())); } throw; } // ... }; In the outermost machine we have: // Base template class for the outermost machines template <typename T> class BaseOutermostStateMachine: public BaseStateMachine<T> { public: // Exception Handling template void exception_caught (Event const& event,FSM& fsm,std::exception& e) { _WARNING_LIB(&fsm.getLogger()," Error during state machine event processing "); _INFO_LIB(&fsm.getLogger(),boost::diagnostic_information(e)); _DEBUG_LIB(&fsm.getLogger()," processing event EvError "); fsm.process_event(EvError()); } template <class FSM> // error during error handling void exception_caught (EvError const& event, FSM& fsm, std::exception& e) { _INFO_LIB(&fsm.getLogger()," exception_caught during processing EvError"); // Propagate the exception out from the fsm. The fsm will be terminated. BaseStateMachine<T>::exception_caught(event, fsm, e); } }; When there is an error in the outermost statemachine we propagate the exception out from it. At this point, the client code (which calls the process_event function) shall restart the state machine therefore resetting it to the initial state. But we cannot simply restart the machine because after we have thrown the exception out from it, it becomes nonresponsive, i.e. it does not react to the fsm->stop() and fsm->start() sequence. So we came up with the following: void Client::reCreateBackEnd() { if(backEnd){ // backEnd is a smart pointer backEnd->stop(); backEnd.reset(); } // Constructing the BackEnd backEnd.reset(new ...); backEnd->set_states( ... ); backEnd->start(); } It is too drastic to recreate the back end, I think. Christophe, is there any more elegant solution to do this? Why is it that the state machine becomes not restartable if an exception is thrown out from it? BR, Gabor