Feature #1770
multi-threaded conversion driver
0%
Related issues
History
#1 Updated by Greg Shah over 11 years ago
Implement a fully multi-threaded conversion driver including all phases of conversion (some phases may have to wait until all files are processed before continuing, but within any given phase it should be highly parallel).
#2 Updated by Greg Shah over 11 years ago
- Target version set to Code Improvements
#3 Updated by Greg Shah over 7 years ago
- Target version deleted (
Code Improvements)
#4 Updated by Greg Shah about 6 years ago
This is an obvious improvement to make that would cut conversion times to a fraction of the current single-threaded time (when run on a multi-processor system). We have tried some simple approaches to make TRPL work in a multi-threaded environment, but it is much more complicated than one might think.
- There are many data structures that are shared and would need to be synchronized. See #1769. This includes data structures that are being directly used by conversion rules as well as much shared state inside the workers, pattern engine, symbol resolver etc...
- There are many uses of a singleton pattern and other static usage for workers which complicate the threading issue. See #1768.
- Properly handle the OO class dependencies such that recursive parsing is done in the correct order and no deadlocks occur.
If it was simple, it would have been done by now. We do plan to fix this, but we will probably not do it before we shift to a cleaner TRPL 2.0 syntax and implementation. This implementation would naturally be multi-threaded and it will eliminate most of the current limitations of the language. See https://proj.goldencode.com/projects/trpl/issues.