Event Loop Introduction

Each pico presents an event loop that handles events sent to the pico according to the rulesets that are installed in it. The following diagram shows the five phases of event evaluation. Note that evaluation is a cycle like any interpreter. The event represents the input to the interpreter that causes the cycle to happen. Once that event has been evaluated, the pico waits for another event.

Open

We'll discuss the five stages in order.

Wait

The wait phase is where picos spend more of their time. For efficiency sake, the pico is suspended during the wait phase. When an event is received the pico engine wakes the pico up and begins executing the cycle. Unsuspending a pico is a very lightweight operation.

Events received by the pico are added to the pico’s event queue and handled in order received. Picos leave the wait phase and enter the decode phase whenever the event queue contains an event to process.

Picos are single-threaded. They do not process events from the event queue in parallel.

Decode Event

The decode phase performs the simple task of unpacking the event from whatever method was used to transport it and putting it in a format that we'll call the request object for this discussion. The request object is used for the remainder of the event evaluation cycle whenever information about the event is needed.

While most events, at present, are transported over HTTP via the Sky Event API, that needn't be the case. Events can be transported via any means for which a decoder exists.  Other transports (e.g. SMTP, XMPP, RabbitMQ, etc.) could be supported with minimal effort.

Schedule Rules

The rule scheduling phase is very important to the overall operation of the pico since building the schedule determines what will happen for the remainder of the event evaluation cycle.

Rules are scheduled using a salience graph that shows, for any given event domain and event type, which rules are salient. The event in the request object will have a single event domain and event type. The domain and type are used to look up the list of rules that are listening for that event domain and type combination. Those rules are added to the schedule.

The salience graph is calculated from the rulesets installed in the pico. Whenever the collection of rulesets for a pico changes, the salience graph must be recalculated. There is a single salience graph for each pico. The salience graph determines for which events a rule is listening by using the rule's event expression.

Rule order matters within a ruleset. The scheduler ensures that rules appear in the schedule in the order they appear in the ruleset. No such ordering exists for rulesets, however, so there is no guarantee that rules from one ruleset will be evaluated before or after those of another unless the programmer takes explicit steps to ensure that they are (see the discussion of explicit events below).

The salience graph creates an event bus for the pico, ensuring that as rulesets are installed their rules are automatically subscribed to the events for which they listen.

Rule Evaluation

The rule evaluation phase is where the good stuff happens, at least from the developer's standpoint. The engine runs down the schedule, picking off rules one by one, evaluating the event expression to see if that rule is selected and then, if it is, executing the rule. Note that a rule can be on the schedule because it's listening for an event, but still not be selected because its event expression is not completely satisfied yet. There might be other events that have to be raised before it is complete.

For purposes of discussing the event evaluation cycle, most of what happens in rule execution is irrelevant. The exception is any raise statement in the rule's postlude. The raise statement allows developers to raise an event as one of the results of the rule evaluation. Raising explicit events is a powerful tool.

From the standpoint of the event evaluation cycle, however, explicit events are a complicating factor because they modify the schedule. Explicit events are not like function calls or actions because they do not represent a change in the flow of control. Instead, an explicit event causes the engine to modify the schedule, possibly appending new rules. Once that has happened rule execution takes up where it left off in the schedule. The schedule is always evaluated in order and new rules to be evaluated are always simply appended. This means that all the rules that were scheduled because of the original event will be evaluated before any rules schedule because of explicit events. Programmers can also use event expressions to order rule evaluation.

If the KRL expressions in the rule makes a synchronous call to an external API (see the http library), rule execution waits for the external resource to respond. If a rule sends an event to another pico, that sets off another independent event evaluation cycle, it doesn't modify the schedule that is currently being executed. Inter-pico events are sent asynchronously. If two picos are running on the same engine, they execute concurrently (although they may not execute in parallel). We cannot make any assumptions about execution order of two picos executing concurrently unless the developer explicitly orders their operations (see Using the Scatter-Gather Pattern to Asynchronously Create Fuse Reports for an example). 

Assembling the Response

The final response is assembled from the output of all the rules that fired. The idea of an event having a response is unusual. For picos it's a historic happenstance that has proven useful. Events raised asynchronously never have responses. For events raised synchronously, the response is most useful as a way to ensure the event was received and processed. But the response can have real utility as well. Responses are optional and depend on the rules that are executed.

Waiting...Again

Once the response has been returned, the pico processes the next event in the event queue or waits for another event if it’s empty.