In summary, a path is created by invoking a create operation on a module and specifying a set of invariants. The invariants describe the properties of the desired path, and are used to determine a next module that must be traversed by data traveling along the path. The process of determining the next module is called making a routing decision, since it affects the route that the path takes through the module graph of the system. Routing decisions are made repeatedly until the path reaches its maximum length. This occurs either when the invariants are no longer strong enough to make a unique routing decision or when the edge of the module graph is reached. Each module that is traversed by a path supplies a partial processing function gi that implements the semantics of the module for the path under construction. A detailed view of a path that traverses three modules is shown in Figure 8. In addition to path creation, there is a path extension operation that allows creating paths when only an interior instead of an endpoint module of the path is known.
Once a path has been created, the path optimization operation can be invoked on it. During this phase, transformation rules are applied repeatedly until none of the rules can be applied any longer. This allows to exploit optimizations that require the full context of the path for proper operation.
Path execution is decoupled from the data arrival and departure processes at the endpoint modules by four queues. For each of the two directions of dataflow, there is an input and an output queue. Typically, path execution involves dequeuing data from an input queue and evaluating the gi functions in sequence until the other end of the path is reached. However, for generality, a message may get absorbed in the middle of a path, or be turned around, or a new message may be created spontaneously inside a path.
The path model defines a mechanism and avoids policy issues to the degree possible. Nevertheless, it is necessary to discuss the policy issues that arise as a result of this model.
Paths create a two-dimensional policy space. One dimension could be labelled length and the other width. The length of a path is related to how many modules it crosses. The width of a path is related to how specialized a path is. A highly specialized path would be considered narrow, whereas a general path would be considered wide. For example, a wide path may process data from many different remote hosts, whereas a narrow path may be tailored for the processing of data from one particular host.
It might seem that it is always desirable to create long and narrow paths. A long path has much of the global context available that is needed to achieve good performance. And a narrow path is specialized which further simplifies the task of creating a well-optimized path. But in reality, paths have costs: it takes both time and space to create them and having many paths means that each path will be used less often, meaning that there is less locality of use. Thus, the choice of whether a path should be long and/or narrow depends completely on the intended use of the path. Tasks that are not performance critical are usually best realized with short and wide paths, whereas performance critical tasks would most likely be realized with long, and possibly narrow, paths.
Since the path model is claimed to be policy-free, what parts of a path-based system do implement policy? Ultimately, it is the invariants that determine the route of a path and its width. Thus the creator of a path realizes policy by specifying more or fewer invariants. Similarly, a module making a routing decision is affecting policy by choosing to either honor or ignore a specified invariant. This means that path policy is not implemented in a well-defined, separate entity but instead is scattered throughout the various modules. This is not surprising since the width and length of a path cannot be specified without taking into account the semantics of each module that is traversed by the path. Of course, it would be possible to define an invariant that specifies the desired length of a path. Limiting a path's length is always possible, but forcing a minimum length is not, since an intermediate module may not be able to make a unique routing decision based on the specified invariants.
When reasoning about paths, it is often helpful to focus on one of the several aspects that make up a path. As a result, paths have many faces. Depending on the context in which they are being discussed or used, a path can be viewed as:
A limitation of the proposed path model is that it does not directly support any form of fan-in/fan-out or multicasting, loosely speaking. In the path model, this would be approximated either by several point-to-point paths or by a single path that covers the common parts and then several small paths that cover the independent parts. The former solution is illustrated in the left hand side of Figure 9, the latter in the right hand side.
The absence of direct support for fan-in or fan-out is a limitation but at the same time a feature of paths. With multiple input or output points, code optimization techniques such as ILP could not always be realized because at path branching points, it would not be clear what module would be entered next. Similarly, for resource management it is often useful to know what the exact source or the destination of a data-item is. With fan-in and fan-out, this question could not be answered for all paths and would thus largely defeat the purpose of paths.