Execution
Understanding Execution in Proto
This article explains execution and processing in Proto
Introduction
Modules in Proto communicate by sending and receiving messages over connections. This article explains the logic behind executing any communication in Proto by helping you to understand how and when messages are sent.
Execution
A custom module is executing whenever its contained modules are processing data or sending and receiving messages. At any given time, Proto is either executing or awaiting the start of an execution cycle. An execution cycle can begin at any module and will continue along each appropriate connection in its execution path. For example, if a Slider and a Text Box are connected via their “Get Value” and “Set Value” connectors, execution begins with the movement of the Slider’s control in the Viewer. The Slider first calculates and store the value of its control’s position and then sends the new value as a message to the connected Text Box. The Text Box then receives the Slider’s value, displays it as text in the Viewer, and sends appropriate messages to any triggered output connections. This execution cycle continues until each of the connected modules in the execution path receives and sends all necessary messages.
An execution cycle can begin in a module as the consequence of any of the following actions:
- A change to its Property Panel
- An interaction with its Viewer control
- A connection being made from a fire-on-connect output connector
- Some internal process originating in the module such as an Excel Reader reading an updated Excel sheet
After the originating module completes its internal processing, it continues the execution by sending messages to all of its appropriate output connections in no particular order. The connected modules receive these messages on their input connectors, process them internally, and propagate newly processed messages to their corresponding output connections. (The “Output Menu” section of each module’s documentation specifies under which particular circumstances each output connector is triggered). Unless a module encounters an error, this execution cycle will continue until its logical end—when no more triggered connections exist.
Loops and Passive Connections
To avoid complications, the Builder prevents the creation of any non-linear connection paths in custom modules. However, it is sometimes desirable for a message sent from a module to eventually return to the originating module, possibly through an arbitrary number of intermediary connections. With regular connections, this execution would have no logical end to its circular path and would result in an infinite processing loop. In order to allow data to return to its originating module any looped execution paths must contain a passive connection. A passive connection transmits messages to its receiving module’s input connector but does not allow that module to send any resulting messages to any of its output connectors. Passive connections prevent infinite loops by restricting looped connection paths to a single cycle per execution.
Plug-in Connection
Normal connections only allow information to flow in a single direction—from the output connector of one module to the input connector of another. Connecting one module to another as a plug-in allows the host module to use the plug-in module as a part of its internal processing, which is separate from the message execution logic.