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
63
64
65
66
67
68
69
70
71
72
|
# 022 — HTTP 연결에서 분리한 작은 실행 코어
2026-09-23. 상태: 저장·범위 선택 프로필의 구현과 정확성 검증.
첫 공개 체크포인트의 일부이며 통합 OS·범용 앱 실행·고성능 RPC 완성 보고가 아니다.
## 실제로 바뀐 책임
이전에는 HTTP `Connection`이 본문 할당·예산·저장 호출·해제를 소유했다.
이제 `runtime.c`가 작업 슬롯과 세대, 입력 예산과 소유권, 준비 대기열, 효과 실행,
결과 보유·회수를 관리한다. 서버는 바이트를 받아 접수된 입력을 채우고, 완료 결과를 전송한다.
본문이 일부만 도착하고 끊기면 준비되지 않은 작업을 해제하므로 저장 효과가 발생하지 않는다.
코어는 호출자가 제공한 작업 슬롯을 사용한다. 영역마다 스레드·소켓·힙·큰 큐를 만들지 않는다.
준비된 `PureProgram`은 읽기 전용으로 공유할 수 있다. 현재 효과는 영역에 연결한 `PureHost`의
동기 읽기·쓰기·할당 함수다. 파일·매핑·할당 구현은 `store-port.c`에 있고 HTTP는 `server.c`에 있다.
이 API는 C 내부 연결 계약이며 메모리 격리·안정된 외부 ABI·포괄적 권한 시스템은 아니다.
준비된 프로그램의 실행을 `evaluate.c`로 분리했다. `libpure-execution.a`는 `runtime.c`와
`evaluate.c`만 포함한다. 서버는 소스 로딩을 위해 여전히 별도로 `program.c`를 링크한다.
코어 아카이브가 작다는 이유로 서버 전체에서 파서 비용이 사라졌다고 해석하지 않는다.
## 내부 연결과 수명
완료된 결과를 다른 영역의 입력으로 전달하면 코어가 원본 작업을 pin한다. 중간 버퍼 할당·
직렬화·소켓 전송 없이 같은 데이터 구간을 사용하며, 생산자 쪽 호출자는 자신의 티켓을
먼저 해제할 수 있다. 마지막 소비가 끝나야 원본 메모리·매핑이 반환된다.
한 결과의 여러 소비자 중 하나가 취소돼도 나머지 소비자의 참조는 유지한다.
전달된 입력을 응답에서 사용하지 않는 프로그램은 저장 효과가 끝나면 원본을 일찍 해제한다.
긴 전달 연결의 회수는 반복문으로 처리한다. 1,024개 연결 검사는 재귀적 해제로 스택이
증가하지 않고 할당 한 개를 마지막에 한 번 회수하는지 확인하는 수명 검사다. 성능 벤치마크가 아니다.
각 영역의 예산은 자신의 유지 입력·출력에 대한 접수 크레딧이다. 공유된 데이터를 영역별로
청구하므로 여러 영역의 크레딧을 합해 물리 메모리라고 주장하지 않는다.
종료는 새 접수를 막고 기존 작업을 배출한다. 진행·완료·대여 작업이 남은 영역의 재시작은
거절하며, 완전히 배출된 뒤 재시작해도 티켓의 단조 증가 세대는 유지한다.
이전 티켓은 새 작업의 결과를 읽거나 해제할 수 없다. 실행 전 취소와 효과 실행 후 결과는 구분한다.
## 검증 근거
[원시 결과](../../prototypes/connections/results/2026-09-23-execution-core/)의 native·ASan/UBSan
빌드에서 기존 28개 실제 TCP 시나리오와 실행 코어 검증을 통과했다.
기존 범위 의미 비교 3,584개와 필드 경계 사례 48개, 저장 실패·매핑·전송 검사도 유지했다.
추가로 확인한 것은 다음과 같다.
- 준비되지 않은 입력·취소·대기열 제거는 저장 효과를 실행하지 않는다.
- 슬롯·바이트 예산 포화, 할당 실패, 제공되지 않은 쓰기 권한은 접수/실행 경계에서 처리한다.
- 호스트 호출 중 같은 영역의 재진입을 거절한다. 읽기 호스트가 반환 한도를 어겨도 자원을 회수한다.
- 완료 결과의 두 소비자 중 하나를 취소하고 생산자의 티켓을 먼저 해제해도 나머지 결과는 유효하다.
- 실제 입력 숫자로 선택한 `bcd`를 첫 영역에 저장하고 두 번째 영역으로 전달해 별도 저장소에 보존한다.
- 파일을 매핑한 결과를 다른 영역에 넘긴 뒤 원래 저장 객체를 교체해도 이전 내용으로 완료한다.
- 잘못된 입력 범위는 실제 저장 파일을 만들지 않는다. 종료 뒤 모든 영역의 작업·크레딧은 0이다.
## 크기와 한계
Linux AArch64, GCC `-O2`에서 확인한 구조체 크기는 영역 192 B, 작업 슬롯 224 B,
티켓 24 B, 공유 가능한 준비 프로그램 648 B다. 본문·호스트 자원·스택·allocator·RSS는 별도다.
GNU `size`의 코어 두 오브젝트 `text` 합은 5,672 B이며 데이터·BSS는 0 B다.
이는 코드/읽기 전용 섹션 등에 대한 도구 수치이며 전체 프로세스 RAM이나 아카이브 파일 크기가 아니다.
코어 아카이브의 외부 심볼은 `memcpy`, `strlen`과 아카이브 내부에서 해결되는
`pure_program_input`이다. 파서·할당기·파일·소켓·스레드 API를 직접 참조하지 않는다.
8개 작업 슬롯을 추가한 서버 구조체는 이전 39,824 B에서 41,488 B로 **1,664 B 증가**했다.
HTTP 버퍼가 여전히 대부분을 차지한다. 이 변경은 RAM 절감 결과가 아니라 영역별 작업·수명
관리를 추가한 비용을 명시한 것이다. 선택 기능을 제거한 전체 실행물과 실제 앱의 비용 검증은 남았다.
현재 쓰기는 동기 파일 호출이며 오래 걸리는 효과를 선점하거나 다른 실행 영역의 지연을
보장하지 못한다. core 제어 API는 한 소유 스레드에서만 사용한다. 입력은 여전히 전체 본문을
받은 뒤 실행하며, 작성 프로필도 get/put·하나의 저장 효과에 한정된다. 소스 문법의 HTTP 명칭
제거, 일반 앱 연산, 비동기 효과, 자체 RPC·TLS, 네이티브 UI, macOS 실사용 검증은 남아 있다.
이 결과로 Kitex·QUIC보다 빠르거나 네이티브 코드를 강제 격리한다고 주장하지 않는다.
|
