1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
|
# 029 — 작성된 바이트 편집을 실제 네이티브 창에서 실행
2026-09-24. Linux AArch64, C17/GCC 14.2, GTK 4.18. 첫 공개 체크포인트의 중간 결과다.
기존 [문서 편집 연결](023-document-edits.md)을 GTK 창에 붙였다. CLI·HTTP 서버·창이
동일한 [`editor.pure`](../../prototypes/connections/examples/editor.pure) 정의를 준비해
동일한 실행 코어와 조건부 바이트 저장 효과를 사용한다. GTK는 **선택한 앱의 호스트
어댑터**이며 기본 코어·CLI·서버에 들어가지 않는다.
## 실제 사용 경로
`make -C prototypes/connections window`로 선택 빌드한다. 실행 명령은
[사용 안내](../../prototypes/connections/README.md#네이티브-문서-창)와 같다.
창은 저장된 UTF-8 문서를 열고, GTK 텍스트 버퍼에서 편집하며, 이전 내용과 새 내용의
공통 앞·뒤 구간을 찾아 바뀐 바이트 구간만 `store.splice`에 보낸다. 공통 구간이 UTF-8
코드 포인트의 중간에서 끝나면 양쪽을 문자 경계로 넓힌다. 수정하지 않은 기존 본문은
입력 메시지에 다시 싣지 않는다. 저장 구현 자체는 새 파일에 전체 범위를 다시 기록한다.
저장 조건은 읽은 문서 버전이다. 다른 실행기가 먼저 저장했을 때 창은 충돌을 표시하고
현재 초안을 유지한다. `Reload`는 미저장 초안이 있으면 거절하고, `Discard & reload`만
명시적으로 초안을 버린다. 창 닫기·Ctrl+W도 미저장 변경을 확인한다. 수정 없이 저장하면
저장 버전을 올리지 않는다. 이 창은 일반 바이트 편집기가 아니어서 유효하지 않은 UTF-8이나
NUL이 든 저장 문서는 열지 않고 기존 화면을 유지한다. 해당 바이트는 기존 CLI가 다룬다.
## 실제 프로세스 검증
[Xvfb/GTK 사용자 흐름 결과](../../prototypes/connections/results/2026-09-24-native-document-window/gtk-flow.json)와
[ASan/UBSan으로 계측한 C 호스트 결과](../../prototypes/connections/results/2026-09-24-native-document-window/gtk-sanitized.json)는
실제 창의 입력·저장·재시작을 검사한다. 빈 문서 생성·복원, CLI에서 창 저장 내용 확인,
HTTP 서버가 먼저 문서를 갱신한 뒤 창의 충돌·초안 보존, UTF-8에서 첫 두 바이트가 같은
다른 글자로 교체, 변경 없는 저장, 미저장 종료 방지가 통과했다. 1 MiB 문서를 창에서 열고
마지막 한 바이트를 바꾼 뒤 CLI로 전체 결과를 대조했다. 계측 빌드에서 GTK 라이브러리
자체가 ASan으로 재빌드된 것은 아니다.
기존 [연결·저장 회귀 검사](../../prototypes/connections/results/2026-09-24-native-document-window/connection-check.json)도
통과했고, [실행 코어 예산 검사](../../prototypes/connections/results/2026-09-24-native-document-window/core-budget.json)의
`text`는 이전과 동일한 5,932 B였다. 창용 코드는 `make all`의 필수 대상이 아니다.
## 비용은 계층별로 기록
같은 호스트의 [ELF 섹션 원자료](../../prototypes/connections/results/2026-09-24-native-document-window/size.txt),
[stripped 파일 크기](../../prototypes/connections/results/2026-09-24-native-document-window/stripped.txt),
[직접 동적 의존성](../../prototypes/connections/results/2026-09-24-native-document-window/dependencies.txt),
[빌드·소스 해시](../../prototypes/connections/results/2026-09-24-native-document-window/build.json).
| 선택 실행물 | ELF `text` | stripped 파일 | 직접 동적 의존성 |
|---|---:|---:|---|
| 문서 CLI | 35,807 B | 67,904 B | libc |
| HTTP 호환 서버 | 42,761 B | 68,000 B | libc |
| GTK 문서 창 | 43,308 B | 68,280 B | GTK·GIO·GObject·GLib·libc |
창에서 1 MiB 문서를 연 뒤 Linux `/proc`로 본 **창 프로세스 RSS는 44,208 KiB**였다.
Xvfb·커널 캐시·다른 프로세스는 포함하지 않은 수치다. ASan 빌드의 RSS는 143,168 KiB로
별도 검증용이며 제품 비용과 비교하지 않는다. GTK의 공유 라이브러리·렌더링·텍스트 버퍼
비용을 무시하고 68,280 B 파일을 앱 전체 크기라 부르지 않는다. 이것은 마이크로 코어를
실제 문서 앱에 연결한 결과지만, **전체 GTK 앱이 임베디드급 메모리라는 증거는 아니다.**
현재 한계는 단일 문서, 동기 저장, 버전 충돌 후 수동 재적용, GTK/Linux 호스트, 바이트
기반 저장이다. IME·문자소 단위 위치·큰 문서의 대화식 지연·macOS 실사용은 검증하지
않았다. 이후 [030](030-authenticated-document-peer.md)에서 선택형 인증 TLS 피어까지
**같은 문서 작업**으로 연결했다. 실제 앱의 전체 피크·실패·사용성 비용은 계속 검증해야 한다.
|
