Repository navigation
The quit's walk stays in the kernel, and the manual says what a quit request does - #1218
Conversation
Review of #1218 at 24ab5a4Architecture. This PR changes only Markdown. The decision is that the quit's walk of a subtree stays in the kernel, and it fits what the kernel is for. The check of whether a process listens and the claim for its end are one act, done under the table lock and the notice's lock. The walk also reaches each process directly, so a deaf or hung process in the middle of a tree cannot shield what is below it. A relay in userland could provide neither guarantee. The kernel adds no policy, because it never asks on its own. The manual against the code. I verified the following:
The deleted record. Its exit was "the design says which reading holds; this file is deleted", and Overlap. BLOCKERSNone. SUGGESTIONS
LAND |
…request does The record asked which of two readings of the design holds: a parent asks its children to quit over its own protocol and the kernel keeps only the kill, or the kernel's walk of the subtree is the mechanism the interrupt, hang-up and terminate events need. The orchestrator decided the second. Why the walk stays: whether a process listens and whether it is claimed for its end are checked and acted on as one act under one lock, which the process-lifecycle model checks, so no read comes between them; a hung or deaf process in the middle of a tree cannot shield what is below it, since the walk reaches each process itself; and the userland alternative needs a listener in every process and a relay in three runtimes to carry a request down (the orchestrator's analysis; not re-derived here). The authority page now states it: a holder of a child's handle may ask its subtree to quit with a reason, a listener receives it as an event, one that never listened or has not taken the last request is ended, and the kernel never asks on its own. "Quitting gracefully is the parent's job" is replaced by that last clause, which is the part of it that was true. The sessions page read as if a sign-out offered every app the chance to finish, and as if a second request ended a process that ignored the first. What happens: the first ask ends at once every app that never listened; a second request ends a process that has not yet taken the first and asks again one that has taken it; a process that took a request and carries on is ended only by a force. issues/the-kernel-decides-who-is-asked-to-quit-and-who-is-killed.md is deleted and its one citation, in the kernel inventory's list of unresolved design changes, with it. The durable rule already stands at the site that owns it, kernel/proclife/src/quit.rs's header. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
24ab5a4 to
dd0ceb7
Compare
|
Orchestrator: verified dd0ceb7 against review LAND at 24ab5a4. The range-diff shows only suggestions 1 and 2 taken ( |
Closes the design question
issues/the-kernel-decides-who-is-asked-to-quit-and-who-is-killed.mdby the orchestrator's decision: the quit's walk stays in the kernel. Records and the manual only; no code changes.Decision and reason
The record asked whether a parent should ask its children to quit over its own protocol (the kernel keeping only the kill) or whether the kernel's walk is the mechanism the interrupt, hang-up and terminate events need. The second holds:
kernel/proclife/src/quit.rs, checked by the process-lifecycle model), so no read comes between the check and the claim;What changes
docs/src/architecture/authority.md, the process tree: a holder of a child's handle may ask its subtree to quit with a reason; the kernel carries the request to every process below; a listener receives it as an event; one that never listened, or has not taken the last request, is ended; the kernel never asks on its own. This replaces "quitting gracefully is the parent's job".docs/src/architecture/sessions.md, ending a session: the page read as if a sign-out offered every app the chance to finish and as if a second request ended a process that ignored the first. What the code does (system/session/src/lib.rs,kernel/proclife/src/quit.rs): the first ask ends at once every app that never listened; a second request ends a process that has not yet taken the first and asks again one that has; a process that took a request and carries on is ended only by a force. A second request is sent only by a person's action or the machine's stop (Owner::stoppingasks every app again with a terminate after a control's hang-up). The page now says that.issues/README.md's closing procedure) and its one citation, inissues/the-kernel-is-small-interrupts-post-and-threads-wait.md's list of unresolved design changes, removed.git grepfor the slug and the title finds nothing else. The durable rule already stands inkernel/proclife/src/quit.rs's header, so nothing is folded.Checks
Markdown only: no build or test run. No build gate reads
docs/orissues/(searchedbuild/and.github/workflows). Verified by reading:quit::decide/quit::askfor the listen/unread rule,Owner::sign_out/stoppingfor what a sign-out sends, and thatSYS_PROCESS_QUIT(kernel/src/syscall/proc.rs) isquit_process's only caller.Left as it was, unverified
The sessions page still names "the system controls' stop" as an explicit force. The session owner's stop is a terminate request that waits (
Owner::stopping); whether the supervisor then forces is the supervisor track's design and I did not change the sentence's claim.Rebased onto main 67713cb for review round 1 (suggestions 1 and 2 taken, commit-message typo fixed). #1241 removes the adjacent inventory bullet and rebases after this lands.
🤖 Generated with Claude Code