TTRuntimeManager

A runtime manager is a higher level entity in the TickTalk system that serves to coordinate the setup and teardown of the TickTalk system and runtime, including notifying TTEnsembles of each other, generating a mapping (with TTMapper) of the graph, distributing the SQs to ensembles, injecting initial tokens into the system to kickstart graph interpretation and logging final output tokens for future analysis. In other words, the runtime manager handles the management plane of the system.

The TTRuntimeManager is effectively another TTEnsemble, but differs in that it implements an extra process, TTRuntimeManagerProcess. In essence, the TTRuntimeManager is really a wrapper for this process, and is best suited as the user-facing device so the user can see other ensembles in the system connect and personally trigger a graph to be instantiated and interpretation started once the system is setup per their needs.

class ticktalkpython.RuntimeManager.TTRuntimeManager(log_file, name='runtime-manager')

An entity to manage the environment at runtime. The program starts from here, getting mapped to ensembles either dynamically or according to extant information within the SQs in the graph. This is technically an ensemble in that it has a network interface. Simulated and physical variants exist for this as child classes, similar to the network interfaces.

instantiate_and_map_graph(graph: TTGraph)

Signal the runtime manager process to instanatiate the graph for execution by generating a mapping to of SQs to ensembles and distributing those SQs accordingly

Parameters:: graph (TTGraph) – The graph representing a TTPython program to execute

send_to_runtime(msg)

Only the runtime manager process will actually interact with the rest of the system; this simply serves as a proxy from the user-level environment (the main process on the machine hsoting the runtime manager)

Parameters:: msg (Message) – The message to pass to the actual runtime manager process

class ticktalkpython.RuntimeManager.TTRuntimeManagerPhysical(log_file, ip, rx_port, tx_port, name='runtime-manager')

A runtime manager on a physical device; one ensemble will take on this coordination role.

Parameters:

ip (string) – The IPv4 address of the runtime manager. Must be accessible by all other ensembles that wish to join the system.
rx_port (int) – The port the runtime manager ensemble expects to receive input messages from
tx_port (int) – The port the runtime manager plans to use for sending outputs to other ensembles in the system

class ticktalkpython.RuntimeManager.TTRuntimeManagerProcess(log_file, input_queue, ensemble_name=None)

A priveleged process included only on the runtime manager ensemble that can receive from and send into the TTNetworkManager local to itself. It is responsible for forwarding routing-table additions to all connected ensembles, mapping SQs from the graph (and sending the corresponding messages), sending initial input tokens to trigger graph execution, and logging output tokens.

All TT*Process classes follows the same design patterns. They implement a singular input queue from which they read new Messages, which self-identify their function. After processes are created, they exchange interfacing information, primarily in the form of callback functions. After configuring interfaces, the processes start. Each of these processes spends its idle time waiting for new inputs within a ‘run loop’, responding to messages as they arrive; the responses will modify internal process state and produce new messages for other processes implemented on the Ensemble, which ‘owns’ the processes.

Parameters:

input_queue (queue.Queue | multiprocessing.Queue) – An input queue to serve new data (as Messages) to this process
ensemble_name (string) – The name of this ensemble

get_next_input(): Pull the next input off the input queue.

handle_message(msg): Respond to an incoming message meant for this process. If the message type and recipient do not match expectations, this will return without notification

input_msg(message)

Callback use to provide messages to this process’s input queue.

If this is a simulated environment, we interrupt the process, which is otherwise waiting indefinitely for data to arrive on the queue.

Parameters:: message (Message) – The message intended for this same ensemble

run_phy(): The main run loop for a runtime environment using physical processes, which can take advantage of multi-core processors.

run_sim(sim): The main run loop for a runtime environment using simulated processes, which runs on a single core and can implement many ensembles. Must be run as a simpy.Process

setup_proc_intfc(input_network_func, sim_process=None)

Configure the interface to this process, meaning the callback functions for sending outputs to the other processes. This process needs a callback for each other runtime process, as it may receive inputs for any other process through the network.

Parameters:

input_network_func (functiond process that this class runs inside of. Mainly used for interrupting the simulated variant on input messages. dDefaults to None) – A callback function for providing Message inputs to the TTNetworkManager
sim_process (simpy.Process | None) – A reference to the simulated process that this class runs inside of. Mainly used for interrupting the simulated variant on input messages. Defaults to None

class ticktalkpython.RuntimeManager.TTRuntimeManagerSim(log_file, ensembles, sim, name='runtime-manager')

A simulated runtime manager. Can directly access any reference to another ensemble, clock, SQ, etc.; uses a simulated network interface. This is is mainly used to configure the ensemble acting as the Runtime Manager

Parameters:: ensembles ([TTEnsemble]) – A list of the ensembles that compose the system. This may be empty, in the case where the other ensembles are created after the runtime manager starts (such that they join the TickTalk system as any physical ensemble would).

ticktalkpython.RuntimeManager.logger = <Logger TTPython.RuntimeManager (DEBUG)>: default name for the runtime manager ensemble. Other ensembles generally assume there is one runtime manager, and it goes by this name. This is how they build the first entry to their routing table and send a message to ‘Join’ the network of ensembles