diff options
Diffstat (limited to 'docs/research/066-application-boundary.md')
| -rw-r--r-- | docs/research/066-application-boundary.md | 65 |
1 files changed, 65 insertions, 0 deletions
diff --git a/docs/research/066-application-boundary.md b/docs/research/066-application-boundary.md new file mode 100644 index 0000000..44e6d86 --- /dev/null +++ b/docs/research/066-application-boundary.md @@ -0,0 +1,65 @@ +# 066 — 작은 코어에서 하나의 앱 경계 만들기 + +2026-09-24. 첫 공개 체크포인트를 위한 당시 코드 경계 조사. 아래 수치는 변경 전 +기준선이고, 문서 해석을 코어 밖으로 옮긴 결과는 [068](068-opaque-app-core.md)에 있다. + +## 현재 코드가 증명하는 것과 못 하는 것 + +`prototypes/connections/runtime.c`는 입력 접수, 바이트 예산, 작업 슬롯, 완료, +대여와 다른 영역으로의 무복사 전달을 소유한다. 하지만 실행 단계에서 +`PureProgram`의 저장 전용 `read`/`write`/`splice`를 직접 해석하고 +`PureHost.read`/`write`/`splice`를 호출한다. 따라서 현재 5,980 B 코어는 +**범용 앱 코어의 크기**가 아니라 **문서 저장 실행 프로필의 크기**다. + +`prototypes/workbench/native/app.c`는 별도의 `PureScalarPlan`을 실행한다. +터치·키·숫자 입력은 `write("event")`, 상태 스냅샷은 `read("snapshot")`, +복원은 `write("restore")`라는 호스트 키로 연결된다. 수명·예산·저장·복원은 +같은 `PureRuntime`을 통과하지만, 작성한 scalar 규칙이 문서의 바이트 효과를 +선택하거나 거절하지는 못한다. 두 문법을 한 앱 표현이라고 주장할 수 없다. + +이 차이를 없애려고 모든 입력을 범용 객체로 포장하거나 코어에 새 VM, +프로세스 관리자, 프로토콜 파서를 추가하면 마이크로 목표와 충돌한다. +기존 작업물에 **숫자 계산과 바이트 효과가 함께 필요한 한 작업**을 추가해 +필요한 경계만 추출하는 순서가 더 검증 가능하다. + +## 첫 통합 작업과 실패 조건 + +기존 문서 편집 앱의 부분 수정 경로에 작성 가능한 크기 정책을 연결한다. +입력은 현재 문서 길이·제거 길이·삽입 길이·설정된 한도이고, 결과는 +저장 효과의 허용 여부와 오류다. 허용되면 기존의 조건부 splice가 실제 +바이트를 처리하고, 거절되면 저장소와 리비전은 변하지 않는다. 정책은 +CLI·TUI·인증 피어가 같은 준비된 앱 정의에서 읽어야 한다. 단순히 각 +호스트에 같은 `if`를 복사하면 이 실험은 실패다. 정책만 있는 새 데모나 +별도 언어를 만드는 것도 실패다. + +필요한 입력·출력 계약은 작다: 검증된 정수 길이, 조건부 효과 결정, +대여한 바이트 범위, 버전, 결과 상태. 호스트가 소유한 파일·소켓·화면 +핸들은 이 계약의 일부가 아니다. 연결될 때만 작업 슬롯과 payload 예산을 +사용하고, 유휴 앱마다 작업자·큐·힙을 만들지 않는다. + +검증은 실제 문서에 대해 한도가 허용/거절하는 수정, 버전 충돌, 1 MiB +본문, CLI/TUI/피어 간 동일 결과, 실패 시 상태·리비전 불변, 대여 회수를 +포함한다. 정책을 수정한 뒤 동작이 바뀌는 작성 경로와, 파서를 제외한 +고정 실행 경로도 각각 확인한다. 비교 대상은 정책을 호스트 C 코드에 +직접 구현한 동등 기능이다. 지연·메모리 우위는 측정 전까지 주장하지 않는다. + +## 코어 경계와 크기 합격 조건 + +현재 저장 전용 `PureProgram` 해석과 `splice` 필드는 앱/효과 어댑터의 +후보이다. 우선 실제 문서 앱과 scalar 앱의 작업에서 공통인 접수·예산· +완료·대여·전달만 분리하고, 각 앱의 계산과 외부 I/O는 선택형 코드로 +유지한다. 이 과정에서 기존의 취소, 비동기 완료, 다중 영역 전달 계약을 +깨지 않는지 확인해야 한다. 이름만 `read/write`에서 `input/output`으로 +바꾸는 작업은 의미가 없다. + +현재 [기본 코어 예산](../../prototypes/connections/core-budget.json)은 Linux +AArch64/GCC의 `text` 6 KiB, 유휴 영역 128 B, 작업 슬롯 216 B 상한이다. +통합 뒤에도 기본 코어, 선택한 앱의 링크 코드·전체 RSS·유휴 인스턴스, +실제 작업당 payload/복사량을 **각각** 비교한다. 코어 밖으로 비용을 +옮겨서 전체 앱이 커졌다면 개선으로 취급하지 않는다. 문서 앱의 기존 +크기·내구성·복원 검사를 통과하지 못해도 채택하지 않는다. macOS arm64 +빌드·실행 증거는 별도로 필요하다. + +이 통합이 성공한 뒤에야 UI와 저장 외의 네트워크/RPC 입력에 같은 계약을 +적용한다. 이것은 OS 프로세스, pod 또는 VM을 상시 생성하겠다는 계획이 +아니다. 강제 격리가 필요한 배치는 호스트 경계의 선택으로 남긴다. |