#87 Invalidated events use queue space

[Simon Wright]

At present (20150415 release), invalidated events - specifically, held events - remain on the queues until they bubble to the top, at which point they are discarded.

This design is all very well for the unrestricted runtime, but when there’s an upper bound to the queue length it can lead to failure. For example, in the stm32f4 version of the stairwell demo, pressing all four buttons in quick succession (that is, within 5 seconds) will exceed the held event queue’s capacity (16).

The reason for the current design was, I think, uncertainty as to when it would be safe to delete an event. A held event could be invalidated because the event was revoked or because the instance was deleted (for dispatchable events, only because the instance was deleted). The restrictions imposed by Ravenscar (basically, using POs rather than task entries) may simplify this area.

[Simon Wright]

Commit [801511] deleted held events when Unset. However, that still left a space (while the event was between the held event queue and the dispatchable event queue) where it might have been missed.

The insight required was that we don’t need two POs; one PO (of twice the complication, of course) does the trick, The old Held_Event_Processing task only now needs to tell the PO to loop through the held event queue and post any events whose time has arrived.

Fix in [9407d1].

[Simon Wright]

In release 20151101.