Alarmd is currently single threaded. When processing events with alarm data, alarmd must at least do one database query (usually multiple) to create or update the alarm. If the minimal latency for a single query is 5ms, this means that we could at most process 200 events per second.

In order to work around, we should be able to handle events over multiple threads while ensuring that triggers and clears associated to a particular alarm continue to be processed in order.