TTInputTokenProcess

The InputTokenProcess handles token waiting-and-matching by accepting new tokens and passing them to SQs for synchronization and firing rule checks. This process is implemented on a TTEnemble, and only requires TTSQSync and TTClocks to perform its tasks, which includes SQ synchronization and, in some cases, basic control flow for stream generation and deadline checking. The process itself encapsulates these SQs and Clocks with good multiprocessing fundamentals to ensure consistency and memory safety. Most graph-processing implementations are directly within the TTSQSync.

All TT*Process classes follows the same design pattern. 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.

class ticktalkpython.InputTokenProcess.TTInputTokenProcess(input_queue, ensemble_name=None, wait_func=None, wait_until_func=None)

A process to manage incoming tokens, accepting them through a singular input queue. The process will listen to that queue, checking their tags for the SQ of interest. It will then check the firing rule against any present tokens for that tag and context. If the firing rule is triggered, then the relevant tokens are packaged into a TTExecutionContext and sent to the ensemble’s ExecuteProcess, where they will be scheduled and executed. Exact behavior for token management depends strongly on the TTFiringRule.

find_sq_and_sync(token)

The provided token will now be compared to the other tokens currently stored for the SQ within the corresponding TTSQSync object which actually stores tokens and checks the firing rule. If it has a set of tokens that are ready to be executed on, it will return a list of them to be wrapped into a TTExecutionContext and sent to the TTExecuteProcess on this ensemble. These tokens are not returned; we complete synchronization here and forward the result to the TTExecuteProcess

Parameters:

token (TTToken) – The token to send to an SQ and check against the firing rule and extant tokens

Returns:

None

get_next_input()

Pull the next input off the input queue.

Returns:

If present, the next Message from the input queue

Return type:

None | Message

handle_message(msg)

handle IPC (Inter Process Communication) messages arriving to this process via the singular input queue. This will include messages at the data, control, and management planes, which will have designators to specify how they should be handled (using process-specific enumeration)

The input token process will handle messages related to synchronization of inputs for SQs, as well as control messages to instantiate, update, or remove SQs (only the synchronization portion). New tokens constitute the data layer interactions, in which they will be synchronized with other tokens incident on an SQ; when synchronization completes, a TTExecutionContext will be constructed and put into an outgoing queue to the TTExecuteProcess.

Parameters:

msg (Message) – A message read off of the input queue. This must be an Message with a msg_type of SyncMsg and process_recipient of ProcessInputTokens, else it will be ignored without notification

Returns:

None; any ‘return-like’ behavior will produce an IPC message for another process

input_msg(message)

Input an Message to this process. If running in a simulation environment, this will interrupt

Parameters:

message (Message) – A message to provide to this process. Does not need to be called within the same process (i.e. it is not only thread-safe but inter-process safe)

run_phy()

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

It is expected that this will run in its own distinct multiprocess.Process (at the level of the OS with its own virtual memory).

This will listen to the input queue and call a handler for any messages that arrive.

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. This will listen to the input queue and call a handler for any messages that arrive

This must be instantiated using the sim.process() interface, as this function is technically a generator due to its usage of ‘yield’ (an essential component of simpy event processing)

setup_proc_intfc(input_execute_func, sim_process=None)

Configure the interface to this process, meaning the callback functions for sending outputs to the TTExecuteProcess

Parameters:

• input_execute_func (function) – A callback function for providing Message inputs to the TTExecuteProcess

• 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. dDefaults to None