|
tin
1.5.9
|
These are the properties contributors should preserve when changing tin. They are not slogans; they are review criteria.
tin runtime objects do not create framework-owned threads. Queues, channels, actors, tasks, timers, and HSM runtimes advance only when a caller, executor, RTOS task, event loop, or test steps them.
This makes execution order reviewable and lets host tests run the same behavior without target scheduling.
Embedded-facing runtime paths should expose capacity in types, policies, or resource manifests. A reviewer should be able to find:
When a change adds storage, update the resource snapshot, budget, or documentation that explains the new bound.
Backpressure behavior is part of the API. A channel or queue should make clear whether it rejects newest values, drops oldest values, overwrites latest values, or uses another explicit policy.
Callers should handle the acceptance result when losing work matters.
Events are normal C++ types. Use payload fields when behavior, diagnostics, tests, or trace replay need data such as measured values, thresholds, IDs, timestamps, or error codes.
Marker events are fine for pure signals such as BootComplete. Payload events are better when the event records something observed.
HSM definitions should model legal behavior without depending on a board HAL, RTOS header, middleware client, socket library, or simulator API. Those belong at adapter boundaries.
This keeps behavior available to host unit tests and generated tooling.
Time should enter through ticks, timers, task sleeps, or typed timer events. Behavior code should not read wall-clock time directly. This allows replay, simulation, deterministic tests, and target-specific tick sources to share the same behavior model.
Platform-specific code may use vendor APIs, RTOS primitives, linker scripts, or board objects. It adapts those details into tin, tio, thal, or product types for shared behavior.
If a change alters behavior semantics, queueing behavior, IR shape, generated artifacts, or target assumptions, update the corresponding tests and docs in the same change. The repository should not require a reviewer to infer whether the evidence still matches the implementation.