Skip to content

0.19.0 --- kal_task_cores and kal_task_set_priority - #57

Merged
Sunrisepeak merged 3 commits into
mainfrom
openkal-0.19.0
Oct 31, 2026
Merged

Sunrisepeak merged 3 commits into
mainfrom
openkal-0.19.0

Conversation

@Sunrisepeak

Copy link
Copy Markdown
Member

Two operations of openkal.task (clause 11 entry 41): the physical cores beneath the processors a program may run on (zero: cannot say), and the calling context's claim on the processors (DEFAULT, LOW, BACKGROUND; KAL_TASK_PROP_PRIORITY). Motivation and the admission argument are in SPEC.md entry 41 and mcpp design 2026-10-30 part 2 §25.9. Conformance examines both. Implementations: openkal-linux 0.20.0, openkal-macos 0.17.0, openkal-windows 0.15.0, openkal-emscripten 0.8.0 (branches openkal-0.19.0).

Co-authored-by: speak-agent 248744407+speak-agent@users.noreply.github.com

Sunrisepeak and others added 2 commits November 1, 2026 03:46
…es, and a context's claim on the processors

Two operations of openkal.task (clause 11 entry 41).

kal_task_cores answers how many physical cores the contexts this program may
run on are on, zero where the environment cannot say, never more than
kal_task_parallelism. A compiler run as an ok image prepared one module at a
time where the same machine's own program prepared four: it sizes heavy work
by physical cores, its C library had nowhere to ask, and "unknown" became one.

kal_task_set_priority sets the calling context's claim: DEFAULT, LOW,
BACKGROUND. A language server's background indexing competed with what its
user typed, which on its own system it marks as background work. Three claims
rather than a number, because a number obliges a mapping onto environments
that have no scale (clause 7.1), and three are what Linux's scheduling
policies, macOS's quality-of-service classes and Windows' background mode all
say. A context that lowered its claim may be refused raising it
(kal_err_permission); an environment without the operation does not claim
KAL_TASK_PROP_PRIORITY and answers kal_err_not_supported.

Both meet version 0.8's admission criterion: every environment this
specification targets states its cores and lowers a thread's claim in one call
each, and neither can be composed above. Neither touches the core set (clause
3.2). The conformance suite examines both: the cores against the contexts, and
the claims lowered, raised and refused in a started context. Measured against
openkal-linux (24 cores of 32 processors, 272 observations held) and
openkal-windows under Wine (237 held).

Co-authored-by: speak-agent <248744407+speak-agent@users.noreply.github.com>
…neath, implementations differing only where named, and a consumer that reaches past binding itself

openkal is an interface stated in C, a binary interface at clause 4.4's
boundaries, and for an ok image the binary interface at run time with its
loader. The rule they share was implied by clause 1 and clause 7.1 and is now
stated: a consumer observes only what this specification defines; an
implementation may differ beneath (its kernel, a C library, an emulation) and
not in what a consumer can observe beyond what is named open; a program that
calls its environment directly binds itself to it, which an ok image cannot.

Co-authored-by: speak-agent <248744407+speak-agent@users.noreply.github.com>
…e, as measured (limit=2), not four

Co-authored-by: speak-agent <248744407+speak-agent@users.noreply.github.com>
@Sunrisepeak
Sunrisepeak merged commit 73ea0c2 into main Oct 31, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant