Event Concurrency Policies

EventHandler::fireEvent() is the function which fire Asgard's events. It's worth mentioning that fireEvent creates a special kind of SDL event identified as SDL_USEREVENT and inserts that event into SDL's event queue. By doing this, Asgard's events are dequeued in Asgard's Event Handler which is polling the SDL event queue.

We need to add a parameter to fireEvent() called concurrencyPolicy. This parameter could have one of these values:

  1. POLICY_CONCURRENT - allow multiple Event Handling Threads to run concurrently.

  2. POLICY_BLOCK - block future Event Handling Threads from starting for a given Event Type if one thread for such an Event Type is already running. Requests to start new Event Handling Threads will then "queue" up and be started first come first serve.

  3. POLICY_OVERRIDE - if an Event is currently being handled in an Event Handling Thread, that event is signal to come to a stopping point so that the new Event may start a new Event Handling Thread (presumably with different parameters).

  4. POLICY_CANCEL - only one Event Handling Thread may be started for an Event. All subsequent events are cancelled.

CONCURRENT is the default behavior we have today. It's useful, but can be dangerous and lead to erratic responses or out-right crashes.

BLOCK is potentially a strategy for CMO movement. Imagine what should happen if the user clicks in multiple places in sequence. If the events were fired with BLOCK, the CMO would move from spot to the next in sequence as if it's movement had been queued.

OVERRIDE is another potential strategy for CMO movement. Imagine the same scenario where the user clicks in multiple places in a sequence. With the OVERRIDE policy, the CMO would immediately stop moving to the current spot and start walking to the new spot.

CANCEL is the policy we need for Map Pan Events. When the CMO crosses the Map Pan Threshold, multiple Map Pan Events are fired in rapid succession. Unfortunately they're all handled concurrently and Asgard spazzes out and crashes. With the CANCEL policy, only the first event would be handled. All subsequently generated events would be cancelled out and forgotten.

--

It's worth mentioning that Asgard 0.3.8 supports a bare implementation of the CANCEL policy.