# 6. Use a Single Event Queue

Date: 2023-02-13

## Status

Accepted

## Context

Events in an event-driven system must be queued. The question is: one queue, or multiple queues?

## Decision

There will be a single, central event queue in the CPF system. All event-generating code will submit events to this queue. 

The state processing code will consume the queue elements in a single place.

## Consequences

- A dramatically simplified event interface can be created: elements in the system only have to worry about the `CentralEventQueue` and event types. All other details about the event system can be completely hidden from users.
- Events in the system will be serialized and handled in the order that they are submitted.
	+ Serialization will allow for more predictable execution.
	+ Serialization provides the option for recreating history when debugging a problematic sequence of events for debugging purposes.
- Events are handled in the order they are received. There is currently no concept of a high-priority event, nor a separate queue to handle those. Such a queue may be desirable in the future.
- Events will be consumed in a single place: the state processing code.
- Given that there are multiple produces and a single consumer, the event queue push/pop operations should be "locked". Given that this is a single-threaded system, the "lock" should be an interrupt lock: interrupts will be disabled before pushing/popping, and enabled afterward. This will be sufficient to prevent race conditions.
- Improved testability - we can mock a single central event queue with alternative behavior for the test context (e.g., invoke callback events directly instead of adding them to the queue).