Terms like "per-operation controls" are understated in the programming world, and "quantized execution" is the key that makes these terms make sense.
I made a threading architecture that embodies "quantized execution" and "per-operation controls" and learned that the key to a productive codebase is having a "surface of execution" that speaks for itself. Each operation is quantized to a unit of arguments (token) and each unit represents a flowing surface of metadata and heuristics.
The architecture I made TokenGate is described best as "an async threading hybrid model with per-operation controls".
In TokenGate there's two layers of task authority, the first layer is the CPU and IO process tags to control affinity, the second is a direct admin control panel operated on the localhost of the rig running TokenGate.
Example of the control mechanisms in the GUI
Having (per-task or) per-operation commands to change the runtime is helpful, undoubtedly. What I want to discuss is if people would get on board with this if it was simple and practical?
This could be done in a variety of ways and is a huge enhancement to any code base.
As an example; if you had an analysis algorithm for tasks and a flag system, then you could act on this.
In whatever way (there's plenty) a codebase could add controls to 100% of their systems critical operations. They could monitor their successful returns, predict memory needs, stop processes which are failing, and retain "control" by having a functional "surface of truth".
This is possible when you "quantize an execution" or when functions are wrapped and decorated as tokens or if you go savvy with some other dynamic means of analysis and task manipulation. Point is, a "unit of execution" that has a "surface of truth" is much more "programmable" than a series of locked and time dependent operations using generic returns/state.
This doesn't mean all functions are meant to have "controls" but anything which alters or returns data in this perspective should.
Am I the only one who thinks "task controls and analysis" is something that should be more of a conversation?
Also who would be on board with a new paradigm of task execution and analysis like this?
Top comments (0)