Details
-
Type:
New Feature
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 4.7
-
Fix Version/s: 5.0
-
Component/s: Graph Processing Framework
-
Labels:None
Description
Some operators require that their tile computation methods are invoked exactly once during a processing, for example
- operators that write tiles to disk or
- operators that aggregate sample values.
Due to the current multi-threaded nature of tile processing it would be difficult for clients to manage status information in each operator because operators shall not maintain state between tile computation requests. It is therefore obvious that the framework needs to track the tile computation states (but only for operators that require this).
Another solution would be that operators or graphs may in be run different execution modes, e.g.
1. single request: All tiles are computed exactly one time either in parellel or one after the other. From the operators perspective, tile computation invocations are deterministic.
2. multi request: The framework may arbitrarily ask an operator to recompute its tile (e.g. typically a multi-threaded image display in a GUI). From the operators perspective, tile computation invocations are non-deterministic.
Two additional Operator properties (annotations) could be used to determine whether or not an execution mode is applicable for a single Operator or an entire graph:
1. multiThreadingSafe:boolean (framework can use multi-threading in all modes)
2. canRecomputeTiles:boolean (multi request mode not possible)
- operators that write tiles to disk or
- operators that aggregate sample values.
Due to the current multi-threaded nature of tile processing it would be difficult for clients to manage status information in each operator because operators shall not maintain state between tile computation requests. It is therefore obvious that the framework needs to track the tile computation states (but only for operators that require this).
Another solution would be that operators or graphs may in be run different execution modes, e.g.
1. single request: All tiles are computed exactly one time either in parellel or one after the other. From the operators perspective, tile computation invocations are deterministic.
2. multi request: The framework may arbitrarily ask an operator to recompute its tile (e.g. typically a multi-threaded image display in a GUI). From the operators perspective, tile computation invocations are non-deterministic.
Two additional Operator properties (annotations) could be used to determine whether or not an execution mode is applicable for a single Operator or an entire graph:
1. multiThreadingSafe:boolean (framework can use multi-threading in all modes)
2. canRecomputeTiles:boolean (multi request mode not possible)