Re: [boost] [msm] deferral stack overfolw

Subject: Re: [boost] [msm] deferral stack overfolw
From: Richard Szabo (sz.richard_at_[hidden])
Date: 2011-12-08 05:54:16

Hi Chistophe

I have tried in the little example the change you have suggested :

  struct LogDefer
  {
    typedef int deferring_action;
    template <class EVT,class FSM,class SourceState,class TargetState>
    void operator()(EVT const& evt,FSM& fsm,SourceState&
src_,TargetState& ) const
    {
      std::cout << fsm.m_SmName << " DEFERED: " << evt.getName() << std::endl;
      fsm.defer_event(evt);
    }
  };

but it did not help for me .... ?. :(. Sill stack overflow.

Cheers
Richie

On 7 December 2011 12:30, Richard Szabo <sz.richard_at_[hidden]> wrote:
>> Hi Richard,
>>
>> ah, how could I miss this? There is a mistake in your LogDefer functor:
>> typedef int deferring_action;
>
> Ah thanks for finding it ... I will try this out for you.
> In a mean time I have implemented our own event queue.
> But I will give a try to the original one ... it would be better to
> use that anyhow ...
>
> For the VC problem I had to time to play with it at all :( I found a
> one line change in the boost back end to solve my problem ..... I had
> to do this I was under high time pressure .....
> even you disagree :(.
> line :         if (!handled && !is_contained() &&
> !is_completion_event<Event>::type::value)
> changed to : if ( ( handled == HANDLED_FALSE || handled ==
> HANDLED_GUARD_REJECT)  && !is_contained() &&
> !is_completion_event<Event>::type::value)
>
> However I will prepare you a test project with the complexity/size
> similar to our current .... future size / complexity just for
> experiment and also give you a strip down version of our way of
> splitting the state machines maybe you can review it and give some
> ideas how to do thinks better :).
> But it takes some time to prepare this example and I have to check
> where are the limits of sharing our code base with open source
> community .... I personally would be happy to give all as it is but
> the company has different view about it I believe.
>
> I find MSM great I think it is easy to understand very expressive but
> the biggest downsize is the scalability in order to use it for our
> purpose, to write a complex communication protocol stack with a lot of
> events and state machines connected to each other. MSM is not usable
> as it is .... ( sorry to saying that It would hurt me if MSM would be
> my code ) we had to put in some effort to find an semi decent way of
> get around this problem ... So I think there is some work needs to be
> done in this area I'm happy to help as much as I can with it ... eg
> try to prepare an example project for experimenting ....
>
> So thanks for the help ... I will come back to you when I have
> something to play with but it will take some time ... hopefully it can
> be a christmas persent :).
>
> Thans for all the great support ...
>
> Cheers
> Richie
>
>>
>> This should be defined in the functor, not inside operator(). Then there
>> will be no overflow.
>>
>> Cheers,
>> Christophe
>>
>> PS: any news about your VC9 problem?
>>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost