/docs/internals/task_states.txt
Plain Text | 49 lines | 34 code | 15 blank | 0 comment | 0 complexity | 181bb18e6689895d8285d2add4d750cb MD5 | raw file
1See task_states.pdf 2 3Explanation of states: 4 5new: start not called 6 7ready: task.start()/resume() called. Task is in the 8 scheduler q or has been taken out of it and handed to 9 the thread. Note that task.running = true (doesn't reflect 10 the 'running' state below) 11 12running: stack is resumed. task runs normally to completion 13 or until Task.pause/yield/exit is called. 14 15pausing: pause called with a PauseReason object 16 pauseReason can be user-defined. Predefined ones are 17 YieldReason, TaskDoneReason, Empty_MsgAvListener, 18 Full_SpcAvListener etc. 19 20 Task.running remains true until it moves to paused state. 21 22paused: waiting for a message. 23 Task.running = false /\ Task.pauseReason.isValid() 24 25done : task.execute() returned normally or with an unchecked exception 26 or Task.exit() called 27 28==================================================================== 29Messages and task scheduling 30 31What happens when a message arrives in each of the above states? 32 33new: no scheduling on msgs. start() explicitly schedules the task whether 34 or not there are mailboxes. 35 36ready: 37running: 38 no scheduling necessary when msg is put into mbox; task will rcv 39 the message on get() The distinction between ready and running is 40 not really important from a scheduling or message interaction 41 perspective. 42 43pausing: no scheduling yet, because the task is still unwinding, 44 But after the task is fully unwound, it'll be scheduled again if there 45 are messages in an mbox that caused that task to pause in the first 46 place. 47 48paused: Schedule the task. 49