TasksModule

Source: TasksModule.h

TaskListSource

struct TaskListSource

src/core/TasksModule.h:75

Inherits: ListSource

The RTOS task table, a ListSource over a fixed snapshot the platform layer fills.

Kept as a nested source (a dedicated ListSource for the tasks control, distinct from the module class). refresh() re-snapshots on tick1s; the rows serialize from the buffer. No allocation — a fixed TaskInfo[kMaxTasks], filled or left at count 0 (desktop / no trace facility → the table is simply empty).

Public Attributes

platform::TaskInfo rows_

uint8_t count_ = 0

Public Methods

inline void refresh()

inline uint8_t listRowCount() const override

inline void writeListRow(JsonSink & sink, uint8_t row) const override

inline void writeListRowDetail(JsonSink & sink, uint8_t row) const override

Public Static Attributes

constexpruint8_t kMaxTasks = 32

Public Static Methods

static inline constchar * stateGlyph(platform::TaskState s)

TasksModule

class TasksModule

src/core/TasksModule.h:47

Inherits: MoonModule

A core, domain-neutral diagnostic that shows what runs where: the FreeRTOS tasks, with the projectMM MoonModules that run inside each nested beneath it and their live cost.

It is the observability foundation for core-affinity / task-assignment work — you can't optimise which module runs on which core until you can see the cost of each and where it runs.

One nested list: tasks. Each row is a FreeRTOS task (name, state, core, priority, stack high-water-mark; CPU% only in a profiling build); expanding a row reveals the MoonModules that run inside that task, each with its live cost — us (avg loop time), class (instance bytes), heap (dynamic bytes). Those three are projectMM's already-collected self-report (tickTimeUs()/classSize()/dynamicBytes(), see MoonModule), read straight off the live tree, so the cost view is free. Two read-only fields (core0/core1) name the task on each core.

Prior art. MoonLight's ModuleTasks (https://github.com/MoonModules/MoonLight, doc https://moonmodules.org/MoonLight/moonbase/tasks/) is a flat FreeRTOS task table via uxTaskGetSystemState — the textbook RTOS-introspection pattern (behind the platform boundary here: platform::taskSnapshot, no FreeRTOS type in the module). projectMM adds the per-module cost nesting MoonLight lacks. The list uses ControlType::List + ListSource, the read-only data-source/adapter shape (UITableView's data source, Qt's QAbstractItemModel) as DevicesModule.

Bespoke, with reason. Nesting modules under a task is projectMM-specific: its Scheduler runs many modules cooperatively inside one render task (tick() calls every tick()), whereas in a normal RTOS a task is the unit. Today every module runs in the one render task, so that task's detail is the whole module list and other tasks are leaves; the nesting structure is ready for the future core-affinity split, when modules spread across tasks. Built agile, in steps.

Fixed System module. Wired by code as a child of SystemModule in main.cpp (like Improv under Network), not user-added — you don't delete Task Manager. It keeps the base Generic role so no container accepts it as a user-editable child, and markWiredByCode() exempts it from the persistence trim. Read-only: no user-editable controls.

Public Methods

virtual inline void defineControls() override : defineControls MUST be idempotent and pure: only controls_.clear() + controls_.addX().

virtual inline void tick1s() override : Refresh the RTOS snapshot + the current-per-core names once a second (off the hot path).