[RFC] 0014 Task Workers#897
Conversation
RandomByte
force-pushed
the
rfc-task-workers
branch
from
3f4640a to
025954c
Compare
Implementing UI5/cli#897 Based on SAP/ui5-builder#955
Implementing UI5/cli#897 Based on #955
| path: lib/tasks/piProcessor.js | ||
| ``` | ||
|
|
||
| **TODO:** Decide on configuration style. Option 1 does not allow for introducing additional per-processor configuration in the future (e.g. max CPU threads, priority, etc.) |
There was a problem hiding this comment.
I find option 3 the most consistent one, as it has a very similar structure as the task itself, and order does not matter (right?), so there's no reason for option 2.
There was a problem hiding this comment.
I agree and updated that part
* [DEPENDENCY] Bump rimraf from 4.4.1 to 5.0.0 Bumps [rimraf](https://github.com/isaacs/rimraf) from 4.4.1 to 5.0.0. - [Release notes](https://github.com/isaacs/rimraf/releases) - [Changelog](https://github.com/isaacs/rimraf/blob/main/CHANGELOG.md) - [Commits](isaacs/rimraf@v4.4.1...v5.0.0) --- updated-dependencies: - dependency-name: rimraf dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> * [INTERNAL] rimraf: Migrate to named import --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Florian Vogt <florian.vogt@sap.com>
|
|
||
| * A task processor is assumed to utilize a single CPU thread by 90-100% | ||
| * A task processor is assumed to execute little to no I/O operations | ||
| * A task processor is assumed to make little use of UI5 Tooling modules other than those provided directly to the task processor |
There was a problem hiding this comment.
I would go even stricter on this one as the processor (eventually) runs in a thread and it must be totally decoupled from anything else that is not provided as an argument. It's just for the simple reason that even if it tries, it cannot simply access the resources from the main thread like this
| #### Input Parameters | ||
|
|
||
| * **`resources`**: An array of `@ui5/fs/Resource` provided by the task | ||
| * **`options`**: An object provided by the task |
There was a problem hiding this comment.
It must be a serializeable object. Otherwise, when we pass this object to the thread, some information from it could be lost. Also, it would be very painful for debugging
| }; | ||
| ``` | ||
|
|
||
| Option 1 does not allow for introducing additional per-processor configuration in the future (e.g. max CPU threads, priority, etc.). Option 4 can't make use of the existing schema validation of ui5.yaml-based configuration. |
There was a problem hiding this comment.
Maybe, I'm missing something, but if we take the PoC with workerpool, then workers configuration must be in a single, central place, but not within the definition of the processor. We create a singleton instance of the workerpool that is then reused accross the modules / tasks and the configuration of that workerpool happens at the first invocation of the instance.
From that point, maybe it's not feasible to provide such flexibility per processor
4 participants
Concept for a new API provided to UI5 Tooling build tasks, enabling easy use of Node.js Worker Threads to execute CPU intensive operations outside of the main thread.
View rendered version
PoC: SAP/ui5-builder#955
JIRA: CPOUI5FOUNDATION-751