Description
Since the new multi-threading mechanism has been put in place, the notion of job pieces has transitioned from number of threads to number of work units (commit ce15429 and the related work). At many points in the code, the variable holding this number has not been renamed: e.g.
ThreadIdType numberOfThreads = this->GetNumberOfWorkUnits();
such as in
|
ThreadIdType numberOfThreads = this->GetNumberOfWorkUnits(); |
In fact no consistent naming is used for the variable holding such information (e.g. the name nbthreads can also be found).
This naming issue also applies to the remote modules.
Steps to Reproduce
Style change: no impact on the code.
Expected behavior
Increase consistency throughout the code.
Actual behavior
No impact in compilation/tests.
Reproducibility
Does not apply.
Versions
Current head in master branch.
Environment
Does not apply.
Additional Information
The issue was first discussed in PR 10 of the LabelErodeDilate remote module. Some proposals were also discussed.
Description
Since the new multi-threading mechanism has been put in place, the notion of job pieces has transitioned from
number of threadstonumber of work units(commit ce15429 and the related work). At many points in the code, the variable holding this number has not been renamed: e.g.such as in
ITK/Modules/Filtering/ImageIntensity/include/itkShiftScaleImageFilter.hxx
Line 52 in 22ef020
In fact no consistent naming is used for the variable holding such information (e.g. the name
nbthreadscan also be found).This naming issue also applies to the remote modules.
Steps to Reproduce
Style change: no impact on the code.
Expected behavior
Increase consistency throughout the code.
Actual behavior
No impact in compilation/tests.
Reproducibility
Does not apply.
Versions
Current head in
masterbranch.Environment
Does not apply.
Additional Information
The issue was first discussed in PR 10 of the LabelErodeDilate remote module. Some proposals were also discussed.