The executive executes your module by calling the C function that you provide and passing it two arguments: one pointer to an Array for the input Object(s); another to an Array for the output Object(s) the module creates. In each case, the size of the Array is defined by the corresponding mdf file and the number of input and output statements found there.
If a parameter is not specified by the user when the module is called, the corresponding element of the input Array is set to NULL.
As noted earlier, Data Explorer modules are generally required to be pure functions, producing the same results from the same inputs. The reason for this requirement is that the executive caches the results of module execution and does not reexecute the module (given the same input) if the previously computed result is still in the cache.
In particular, modules must not maintain state (e.g., by saving values in global or static variables). Indeed, it may be impossible for a module to maintain state in a multiprocessor environment, since it may execute on a different processor each time. However, a module may use the cache to maintain information that makes succeeding invocations more efficient, provided that it maintains pure-function semantics. (For more information, see 13.5 , "Cache".)
Outboard modules whose PERSISTENT flag is set (see page reference #2) may maintain state, but they are still required to maintain pure-function semantics: the executive might not execute a module if its inputs have not changed and the results are still in the cache. Modules that have no outputs are executed every time a visual program using them is run, regardless of whether or not their inputs have changed. See also Chapter 4. "Data Explorer Execution Model" in IBM Visualization Data Explorer User's Guide.
| For Future Reference |
|---|
|
Although you must supply a C function for Data Explorer to call, it is still possible to write the bulk of a module in FORTRAN: Write a C "wrapper" that (1) extracts the data from the input Object (using the programming interface described in this manual) and (2) passes the data to the FORTRAN subroutine. You should be aware of the following when writing a module that interfaces to a FORTRAN routine:
|