We can easily specify the messaging policies.
The on-arrival rules defined at each gate
can insert the arrived messages to a central queue maintained in
the database.
An (infinite) loop there can activate various event
handlers which process messages in the queue.
The following is only one way to implement a messaging policy,
where implementation of the underlined predicates are
left to the user. These two predicates are policy-dependent.
Timer events and user-posted events can also be processed through
the queue. To do this, the built-in post-event predicates
must be overridden to insert the events into the queue.
But care must be taken so that the post-event predicates
used above still work as intended.
This scheme has significant advantages. First, the need for concurrency control inside the cocavm is ameliorated, since at any moment there is only one rule active in a cocavm. We can maintain a central event queue, which includes all message arrivals, timer or user-posted events, instead of a pure message queue. Second, it is easier to stop the execution of the current rule set say when the participant wants to switch to a different role or a different policy (rule set) at runtime[19]. When the command to freeze the runtime state is received, each cocavm can simply neglect messages with logical time later than that of the freeze command.
This design assumes that predicates in event handlers can finish within a reasonable time. When a blocking predicate is called, it is still feasible to specify a sophisticated threads scheduling policy to suspend the waiting thread and continue to process another event. But if a predicate takes too long or loops forever, however, all the other events must suffer even indefinitely, as such situations are hard to detect mechanically.