TasksModule

Source: TasksModule.h

TaskListSource¶

struct TaskListSource

src/core/system/TasksModule.h:62

Inherits: ListSource

The task table, a source over a fixed snapshot the platform fills, with no allocation.

Public Attributes¶

platform::TaskInfo rows_ : the snapshot itself

uint8_t count_ = 0 : how many rows it holds

Public Methods¶

inline void refresh() : Re-snapshot the tasks, then order them so a row stays put between refreshes.

inline uint8_t listRowCount() const override : How many tasks the snapshot holds.

inline void writeListRow(JsonSink & sink, uint8_t row) const override : Append one task's summary: its name, state, core, priority and stack.

inline void writeListRowDetail(JsonSink & sink, uint8_t row) const override : Append the modules in this task, each one string so the detail view renders chips.

Public Static Attributes¶

constexpr uint8_t kMaxTasks = 32 : a generous ceiling for one device

Public Static Methods¶

static inline bool isMoonLightTask(const char * name) : Whether we created this task: the render task, or a worker under our own prefix.

static inline const char * stateGlyph(platform::TaskState s) : The wire label for one task state.

TasksModule¶

class TasksModule

src/core/system/TasksModule.h:41

Inherits: MoonModule

A domain-neutral diagnostic showing what runs where: the tasks, and the modules inside each.

It is the observability foundation for core-affinity work. You cannot optimize which module runs on which core until you can see it. Header-only: its only platform reach is one seam. A fixed System module, wired by code, and read-only.

Public Methods¶

virtual inline void defineControls() override : Declare the task list and the two per-core readouts.

virtual inline void tick1s() override : Re-snapshot the tasks once a second, the module costs being read live on each serialize.

More info¶

One nested list¶

Each row is a task, carrying its name, state, core, priority and stack mark. A CPU percentage appears only in a profiling build. Expanding a row reveals the modules in that task, each with its live cost. Those figures are the modules' own self-report, so the cost view is free. Two read-only fields name the task on each core.

Why the nesting is ours¶

The scheduler runs many modules cooperatively inside one render task. In a normal RTOS a task is the unit, so nesting modules under one is specific to this design. Today every module runs in that task, so its detail is the whole module list. The structure is ready for a future split across tasks.

Prior art: MoonLight's flat task table, the textbook RTOS introspection pattern.