Closed jakhog closed 6 years ago
I guess the main difference is if the new Session
gets its own copies of the Thing properties (after their value is set to the same as the calling instance.
Well, it looks like you summarized it well. Sessions are basically dynamic regions, if we really want to summarize, except that sessions do not share data (properties) with the "root". I think your point 1. is correct. Also session will die if they reach a final state (there is no way to kill a session rather than forcing it to a final state, e.g. by sending a message).
Good, that's what I thought. When you mention it, it's true that it looks more like a region than a statechart yes. So it seems that in practice you can accomplish this by setting the statechart of the copied instance to a new statechart with contents that of the session.
Thanks! I will get back to work then 🤔
Yes, exactly. In Java/JS we just instantiate the same thing with a different statechart.
Since you seem to be close to a keyboard @brice-morin. Maybe you could explain how the sessions work?
I had a discussion with @ffleurey on friday, and we couldn't 100% decide on how they are supposed to work. As far as I remember, we came down to two options:
When a
fork <session>
is called, a new instance of the calling Thing-type is instantiated. The properties are set to the values of the calling instance, the ports of the new instance is connected to the same ports as the calling instance, and lastly the statechart/behaviour of the new instance is set to the<session>
referenced in thefork
call (which is just aCompositeState
/StateChart
). After this, the new instance continues to live it's own life, independently of the instance that calledfork
.I don't actually remember what the other option was, but it was somehow more related to
Region
s