Robami / pystatecharts

Automatically exported from code.google.com/p/pystatecharts
BSD 3-Clause "New" or "Revised" License
0 stars 1 forks source link

followup of git-hub conversation about events #1

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
You state:
-From: vishpat
-
-Won't the following work for you?
-
-state_chart.param.set_event_data(some_event_data)
-state_chart.dispatch(Event(event))
-
-You can then extract the event data in your action handlers.

I reply:
 I tried it, it works for the simple case, but events are locked in threads, and
event related data is not. This will cause race conditions when I have many 
events in locks passing data outside of locks. It would be better to "lock in" 
the data with the event by making it part of the event.

Original issue reported on code.google.com by r...@haystack.mit.edu on 9 Nov 2010 at 4:06

GoogleCodeExporter commented 8 years ago
I am bit confused here. You can send a single event to the statechart at a 
time, and statechart changes it's state in a discreet step after consuming the 
event. 

Could you elaborate more? maybe I am missing something.

Original comment by vish...@gmail.com on 9 Nov 2010 at 8:22

GoogleCodeExporter commented 8 years ago
The event is discrete, the associated data with the event is not.
The .param.event_data is accessible in the main process and so can be 
overwritten by second sendEvent with associated data that can occur on the 
return from the first non-blocking sendEvent before the event thread as a 
thread-of-control transfers control to the first event receiver and that event 
receiver reads it.

state_chart.param.set_event_data(some_event_data1) #  data available to any 
writer with scope 
state_chart.dispatch(Event(event1))                                 # event in 
thread with locks , nonblocking call
                                                                                               # don't know when it will execute

state_chart.param.set_event_data(some_event_data2)  # overwrites event_data1 
before event1 is handled
state_chart.dispatch(Event(event2))                                   # uh-oh   

Original comment by r...@haystack.mit.edu on 9 Nov 2010 at 9:16

GoogleCodeExporter commented 8 years ago
The event (and so should the data associated with) is consumed after returning 
from dispatch call.

Original comment by vish...@gmail.com on 9 Nov 2010 at 9:55

GoogleCodeExporter commented 8 years ago
The dispatch call is synchronous.

Original comment by vish...@gmail.com on 9 Nov 2010 at 10:10

GoogleCodeExporter commented 8 years ago
but threads are asynchronous - the event "pop" inside the thread might occur 
after the data outside the thread is overwritten.

Original comment by r...@haystack.mit.edu on 10 Nov 2010 at 12:49

GoogleCodeExporter commented 8 years ago
When an event occurs and if you are in a state that hands the event, an action 
handler will be invoked. This action handler can then grab the event data and 
store it in the Param object may be using a hash table.

Original comment by vish...@gmail.com on 10 Nov 2010 at 2:50

GoogleCodeExporter commented 8 years ago
1. I added a self.data to the events class object to hold the event data
    (which meant re-writing Event calls, but I can make the parameter into a default)

2. Note that transition already contains a self.event object

3. When a transition occurs, inside the transition.execute section at the "if 
action" statement I 
simply copy the event into the "param"of self.execute.action(param)

4. inside the action execute(param), I now have access to the event details via 
param.event.data

5. I can now pass parameters from the sendEvent Event into the Action in the 
Transition caused by the Event.

6. I am going to clean it up a bit. Interested in the code when I am done?

Original comment by r...@haystack.mit.edu on 23 Nov 2010 at 6:15

GoogleCodeExporter commented 8 years ago
> Interested in the code when I am done?

Yes, please.

Original comment by qipu...@gmail.com on 27 May 2012 at 7:18

GoogleCodeExporter commented 8 years ago
The problem with open source projects is that there is never enough time. The 
current code set should have the fixes that allow passing parameters - I had a 
summer student clean up bugs in the scb.py tool. I really want to complete the 
gui portion but have to put that on hold for higher priorities.

Original comment by r...@haystack.mit.edu on 30 May 2012 at 12:58