Skip to content

Workflow model

balis edited this page Aug 11, 2014 · 8 revisions

Collections

Description: a process produces or consumes multiple signals (a collection) in a single firing.

Example 1: producing a collection

function foo(ins, outs, config, cb) {
  outs.sig1.data = [1, 2, 3, 4, 5];
  cb(outs);
}

Semantics: function foo returns five instances of signal sig1 which will be emitted separately. (In order to emit an array of elements as one signal, one should use: ins[0].data = [[1, 2, 3, 4, 5]].

Example 2: consuming a collection

In order to consume multiple signals in a single firing, one should utilize Signal quantities (see examples below).

Signal quantity

Constant signal quantity on input

Description: specify how many instances of a given input signal are required to fire a process.

Example:

processes: {
  "name": "Sqr"  
  "ins": [ "square:3" ]
  ...
}

Semantics: process Sqr needs 3 instances of signal square to fire.

Variable signal quantity

Description: dynamically set the quantity of signals required for firing of a process.

Example:

processes: {
  "name": "FileListGenerator",  
  "outs": [ "file:fileCount" ]
  ...
}, {
  "name": "FileProcessor",  
  "ins": [ "file" ],
  "outs": [ "result" ]
  ...
}, {
  "name": "ResultCollector",  
  "ins": [ "result:fileCount" ]
  ...
}
...
signals: {
  "name": "fileCount",
  "control": "count"
}
...

Semantics: when process FileListGenerator produces one or more file signals, it will also emit the fileCount control signal which passes the quantity of file signals to the ResultCollector process. Consequently, ResultCollector will fire only after having received the specified quantity of the result signals.

Control signals

Description

Example:

TODO

Semantics:

Sticky inputs

Description: mark an input signal of a process as sticky. When a signal is consumed from a sticky input, it is not removed from that input queue, so that it can be consumed again. A signal arriving at a sticky input is not enqueued; instead, it replaces the signal currently associated with this input.

Usage: useful for configuration inputs whose values last in multiple firings. Such signals, when marked as sticky, conveniently need not be emitted multiple times.

Example:

processes: {
  "name": "Foo"  
  "ins": [ "bar" ]
  "sticky": [ "bar" ]
  ...
}

Semantics: signal bar will behave as sticky in process Foo.

Firing interval

Description: set a minimum time interval which needs to pass between consecutive firings of a process.

Usage: useful for processes with no inputs, e.g. such that generate input signals for other processes. The firing interval can set the frequency at which such signals are produced.

Example:

processes: {
  "name": "Foo",
  "firingInterval": 1500
  ...
}

Semantics: process Foo will fire not more frequently than every 1500 miliseconds.

Parallelism

Description

Example:

TODO

Semantics:

Clone this wiki locally