IIP

FlowBasedProgramming | RecentChanges | Preferences

Difference (from prior major revision) (author diff)

Changed: 5c5

Under FBP scheduling rules, a component will be reinvoked as long as one connection input port is not drained, so a "parameter" connection port will have to be drained to avoid having the component be continuously reactivated. IIPs on the other hand are passive, and do not take part in scheduling. As they are specified in the network definition, the timing of the component's activation is controlled by other input ports, if any. This suggests that a major attribute of IIP ports is that they do not trigger activation, so can be described as "non-triggering". In fact, in the first FBP implementation, called AMPS, only one input port was used for triggering a particular component (ports were numbered, not named, so this was port zero). Complexities only arise when an IIP is replaced by a regular, data-transporting connection.

Under FBP scheduling rules, a component will be reinvoked as long as one connection input port is not drained, so a "parameter" connection port will have to be drained to avoid having the component be continuously reactivated. The component must close this kind of port to make sure that if an upstream component sends additional IPs, a FlowError.Complain will be generated. A check will be added to the scheduler to make sure that an IIP port has been closed before deactivation.

Changed: 7c7

In the current JavaFBP implementation, a copy of an IIP is presented to a component on every activation: Eric and other people feel that this copying process is counter-intuitive, and that the IIP should only be presented once, making it the component's responsibility to save it, or its contents, somewhere where it can be accessed over more than one activation, e.g. in an instance variable. Any additional receives of the IIP should return null. Of course, if a data connection is attached to this type of input port, we cannot prevent the upstream component from sending more than one packet - this suggests that good practice would be to close the input port after a "parameter" IP has been received. If the upstream output port is marked "optional" (discard undelivered packets), this will not cause a problem. If not so marked, as would normally be the case, an upstream send to a closed port will result in an error indication (Complain).

In the current JavaFBP implementation, a copy of an IIP is presented to a component on every activation: Eric and other people feel that this copying process is counter-intuitive, and that the IIP should only be presented once, making it the component's responsibility to save it, or its contents, somewhere where it can be accessed over more than one activation, e.g. in an instance variable. Any additional receives of the IIP should return null.

Removed: 9,26d8

Attributes: the above suggests that we can take advantage of the new attribute facility, described in C#FBP features, to mark certain input ports with a special "non-triggering" attribute. IIPs can only be attached to non-triggering ports, but regular IPs can also be sent to this kind of port. If all input ports of a component are non-triggering, the component will start at network start-up time - just like the case where there are no input ports at all.

Another advantage of this idea is that this information could then be displayed by a picture-drawing tool, for additional comprehensibility.

Here are the first few statements of a component to read text from a file:


     [InPort("SOURCE", triggering = false)] 
     [OutPort("OUT")]                     // OUT - complain if undelivered mail
     public class ReadText : Component
     {

As there is only one input port, and it is non-triggering, this particular component will start at network start time. Either an IIP or a regular connection can be attached to the SOURCE input port, without the read component needing to know the difference.

If a non-triggering input port is not connected to another component's output port in the network, a receive from that input port will return null. Triggering-type input ports, on the other hand, may not be left unconnected.

Note: In the case of an array port, the triggering/non-triggering attribute applies to all elements.

Initial Information Packet (IIP)

This concept was introduced to FBP by Eric Lawton of IBM, who described an IIP as a chunk of data, defined in the network definition, which turns into an InformationPacket (IP) when the component it is attached to does a receive. This removes the distinction, required by most languages, between parameters and input data. This means that, in FBP, an IIP or a data stream can be attached to a port, without the component needing to know which is which. Typically such ports are used for parametrization, although the IIP does not have to be a parameter - it could just be a piece of constant data being used as a report title, for instance.

Under FBP scheduling rules, a component will be reinvoked as long as one connection input port is not drained, so a "parameter" connection port will have to be drained to avoid having the component be continuously reactivated. The component must close this kind of port to make sure that if an upstream component sends additional IPs, a FlowError.Complain will be generated. A check will be added to the scheduler to make sure that an IIP port has been closed before deactivation.

In the current JavaFBP implementation, a copy of an IIP is presented to a component on every activation: Eric and other people feel that this copying process is counter-intuitive, and that the IIP should only be presented once, making it the component's responsibility to save it, or its contents, somewhere where it can be accessed over more than one activation, e.g. in an instance variable. Any additional receives of the IIP should return null.