Since PlanB is asynchronous, a mechanism is required to temporarily store incoming messages until they can be handled. This is achieved by using a simple, interrupt safe queue mechanism (FIFO), which serves as the main transport mechanism between various parts of the system.
Everything starts with an event being posted into some queue. If the SSM associated with the queue is not yet scheduled, it is. The scheduler then determines when to handle the event.
When the SSM gets processor-time, therefore, it's queue is guaranteed to be filled. It gets an event from the queue and handles them immediately.
If it is allowed to handle more than one event, it will repeat the previous step until the limit is reached or the queue is empty. If there are still events in the queue, the ssm will reschedule itself. If not, it sleeps until the next time someone posts an event to the queue.
The basic granularity of time is therefore determined by the time it takes to handle one event from the input queue. This figure may vary and in fact there is no guarantee it will complete at all. One endless loop will suffice to make that point. Luckily this is not hard to remedy using a simple timer serving as watchdog.
In many cases it is usefull to have an 'out of band' mechanism in order to drive the SSM from within. This achieved by providing two queue's.
This is the main queue discussed above. Events sent to the ssm wind up here.
Intended for 'out of band' events which are handled immediately. They can only be posted from within the current ssm and are handled before any event from the input queue. In this sense, events flow 'backward'. Hence the name. The classic examples being the completione events b_done and b_failed.
Since the backflow queue is guaranteed to be exhausted when the ssm finishes handling an event from the input queue, it suffices to have only one. This saves rather a lot of (valuable when dealing with micro controllers) RAM, or at least allows it to be kept in (fast) cache memory.
In all other respects, the backflow queue behaves just like the input queue.