From b1ce1927022d374198441afafeb27199fc8a052a Mon Sep 17 00:00:00 2001 From: eunhhu Date: Thu, 24 Sep 2026 17:14:54 +0100 Subject: Establish native micro runtime checkpoint --- docs/research/035-native-multi-document-window.md | 66 +++++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 docs/research/035-native-multi-document-window.md (limited to 'docs/research/035-native-multi-document-window.md') diff --git a/docs/research/035-native-multi-document-window.md b/docs/research/035-native-multi-document-window.md new file mode 100644 index 0000000..3aa910f --- /dev/null +++ b/docs/research/035-native-multi-document-window.md @@ -0,0 +1,66 @@ +# 035 — 한 네이티브 창에서 여러 문서를 선택하기 + +2026-09-24. 첫 공개 체크포인트의 문서 창은 CLI·HTTP·인증 피어와 같은 +`editor.pure`를 실행했지만, 시작 인자로 받은 문서 키 하나에 묶여 있었다. +다른 작업물을 보려면 창을 새로 시작해야 했으므로 “작업물을 선택하고 편집하는 +애플리케이션”의 사용 경험이 부족했다. + +선택형 [`edit-window.c`](../../prototypes/connections/edit-window.c)에 문서 키 입력과 +**Open · Ctrl+O**를 추가했다. 유효한 키를 열면 같은 `PureRuntime`과 작성된 +`editor.pure` 경로로 읽는다. 없는 키는 빈 새 문서로 열고, 있으면 해당 버전과 +본문을 채택한다. 읽기 결과를 확인하고 텍스트로 복사한 **뒤에만** 현재 키· +기준 본문·버전을 바꾼다. 따라서 잘못된 키, 읽기 실패, NUL/잘못된 UTF-8이 +든 객체는 현재 문서를 대체하지 않는다. 문서 또는 `.pure` 정의의 초안이 +수정된 상태라면 전환을 막아 둘 다 남긴다. 성공한 전환은 이전 문서의 출력 +표시를 지우고 새 문서의 제목·상태를 갱신한다. + +[실제 GTK 검사](../../prototypes/connections/results/2026-09-24-multi-document-window/gtk-flow-repeated.json)는 +한 창에서 `first → second → third`를 열고 각 문서를 저장·복원한다. +두 번째 문서의 미저장 본문, 수정 중인 정의 초안, 잘못된 키, 바이너리 객체에서 +현재 문서가 유지되는지 확인했다. 기존 외부 HTTP 충돌, 1 MiB 편집, 정의 적용· +실패·재시작 검사는 그대로 통과했다. +[ASan·UBSan 창 검사](../../prototypes/connections/results/2026-09-24-multi-document-window/gtk-asan-repeated.json)와 +[선택형 혼합 저장소의 같은 UI 경로](../../prototypes/connections/results/2026-09-24-multi-document-window/hybrid-gtk-flow.json)도 확인했다. + +## 비용과 배포 + +작업 접수·메모리 수명·효과 실행의 공통 코어는 바꾸지 않았다. 기본 CLI도 +그대로다. 선택형 GTK 창의 링크된 `text`는 앞선 48,247 B에서 **49,882 B**로 +1,635 B 증가했고, 기존 56 KiB 상한과 직접 의존성 검사를 통과했다. +[코드·의존성 결과](../../prototypes/connections/results/2026-09-24-multi-document-window/window-profile.json). +1 MiB 문서를 연 창의 단독 실행 RSS 표본은 **43,920 KiB**였다. 그러나 같은 +창에서 두 개의 1 MiB 문서를 64회 번갈아 열자 RSS가 +**58,752 KiB**까지 증가했다. +[8회 간격 원자료](../../prototypes/connections/results/2026-09-24-multi-document-window/switch-memory-initial.json). +이 증가는 이 작업에서 측정한 프로세스 RSS다. 후속 +[메모리 분리 실험](036-gtk-memory-boundary.md)에서는 증가가 힙에 집중되고 +텍스트 뷰 갱신을 생략한 진단 빌드에서 사라졌다. 정확한 GTK 내부 객체와 +반환 시점은 아직 확인하지 못했다. GTK 문서에 따르면 `GtkTextBuffer.set_text()`는 +[실행 취소 이력에 남지 않는 교체](https://docs.gtk.org/gtk4/method.TextBuffer.set_text.html)다. +이전 버퍼를 매번 새 것으로 바꾸는 실험도 +[증가를 없애지 못해](../../prototypes/connections/results/2026-09-24-multi-document-window/switch-memory-fresh-buffer.json) +되돌렸다. `GtkTextView.set_buffer()`는 [이전 버퍼의 참조를 놓는다](https://docs.gtk.org/gtk4/method.TextView.set_buffer.html). +따라서 이 창을 저메모리 UI의 근거로 삼지 않는다. 기본 코어·CLI의 기존 +크기·메모리·동작 검사 `make check-release`는 통과했다. + +[창 선택 묶음](../../prototypes/connections/results/2026-09-24-multi-document-window/pure-document-window-final-linux-aarch64.tar.gz)은 +49,746 B다. [다른 위치에 풀어 재검사한 결과](../../prototypes/connections/results/2026-09-24-multi-document-window/package-repeated.json)에는 +문서 전환 검사도 포함된다. 패키지 매니페스트는 이 창 기능을 명시한다. +예전 창 묶음에는 해당 표시가 없으므로 현재 검사기는 그 묶음에 새 기능을 +요구하지 않는다. [보관된 창 묶음 재검사](../../prototypes/connections/results/2026-09-24-multi-document-window/legacy-package-repeated.json)가 +통과했다. + +이것은 문서 탐색의 첫 경로다. 아직 키를 직접 입력해야 하고, 목록·검색·메타데이터 +인덱스가 없다. 여러 문서의 원자적 변경도 제공하지 않는다. 현재 작성 언어는 +`get`/`put`의 단일 저장 효과에 국한되고 동기 저장 작업은 GTK 이벤트 루프를 +막을 수 있다. 이 상태를 큰 서비스용 애플리케이션 런타임이라고 부르지 않는다. +다음 구현은 위 실제 앱에서 필요한 다중 객체 탐색·갱신의 의미와 비용을 먼저 +정하고, 그 요구를 실행 모델에 통합해야 한다. 선택형 창을 확장하기 전에는 +[반복 텍스트 교체의 메모리 증가](036-gtk-memory-boundary.md)도 해결하거나 +더 작은 UI 어댑터에서 같은 사용 경험을 검증해야 한다. 단순히 버튼을 더 +붙이는 것은 그 빈칸을 채우지 못한다. + +재현 명령은 `make -C prototypes/connections window check-window-profile`과 +`xvfb-run -a python3 prototypes/connections/check_window.py --build +prototypes/connections/build --program prototypes/connections/examples/editor.pure`다. +64회 메모리 관찰에는 마지막 명령에 `--switch-rounds 64`를 추가한다. -- cgit v1.2.3