threadprocs

이 저장소는 스레드와 유사한 프로세스, 즉 __공유 주소 공간(shared address space)에서 실행되는 여러 프로그램__을 위한 실험적인 코드를 포함하고 있습니다.
각 threadproc은 자신만의 실행 파일, 전역 변수(globals), libc 인스턴스 등을 가진 프로세스처럼 동작하지만, 포인터는 threadproc 간에 유효합니다.
이는 Posix 프로세스 모델과 Posix 멀티스레딩(multi-threading) 프로그래밍 모델을 혼합하여, 포인터 기반 데이터 구조에 대한 제로 카피(zero-copy) 액세스와 같은 기능을 가능하게 합니다.

모든 Markdown 파일은 수동으로 작성되었습니다.

threadprocs를 기반으로 구축된 가능한 애플리케이션 프레임워크 중 하나인 tproc-actors를 참조하십시오.

데모 (Demo)

데모 프로그램의 코드는 example/sharedstr/allocstr.cpp와 example/sharedstr/printstr.cpp에 있으며, 두 코드 모두 어떠한 마법(예: /proc/[pid]/mem 등)이나 서버 및 런처(launcher)에 대한 인식을 포함하지 않습니다.

• allocstr은 입력을 읽어 새로운 std::string으로 복사하고, 콘솔에 &newstring을 출력합니다.
• printstr은 포인터를 16진수 텍스트로 읽어 들여, 그곳에서 발견되는 std::string을 출력합니다.

엘리베이터 피치 (Elevator pitch)

server 유틸리티는 가상 주소 공간(virtual address space)을 "호스팅"하며, launcher를 사용하여 프로그램을 시작함으로써 실행된 프로그램들은 호스팅된 주소 공간 내에서 공존하게 됩니다.

애플리케이션은 어떤 대역 외 메커니즘(out-of-band mechanism)을 통해 가상 주소 공간 내의 포인터를 공유할 수 있으며(데모는 복사/붙여넣기를 사용하고, dummy_server/client는 소켓을 사용하며, libtproc은 서버 전역 스크래치 공간을 제공함), 공유 주소 공간 내에서 해당 포인터들이 유효하므로 _그 포인터들을 직접 역참조(dereference)_할 수 있습니다.

libtproc

libtproc은 threadproc으로서의 실행에 대한 기본적인 탐지를 제공하며, 호스팅된 threadproc이 "서버 전역(server-global)" 스크래치 공간에 접근할 수 있도록 합니다.
애플리케이션은 이 공간을 사용하여 서비스 검색(service discovery)을 구현하고 공유 메모리 기반의 IPC(Inter-Process Communication)를 부트스트랩(bootstrap)하는 도구를 구축할 수 있습니다.

이는 threadproc auxv에 또 다른 항목을 추가함으로써 구현됩니다.

tproc-actors는 이 공간을 사용하여 각 threadproc별 액터 레지스트리(actor registries)를 광고합니다.

상태 (Status)

• examples/ 및 test/ 내 개념 증명 (Proof of concept)
• aarch64+x86_64 Linux
• 프로덕션 품질 (Production quality)
• 보안적임 (Secure(ish))
• 문서화 (Documentation)
• 피어/서비스 발견 (peer/service discovery)을 위한 툴링 (기초적 수준)

시작하기 (Getting started)

aarch64 또는 x86_64 기반의 Linux를 사용하세요. 다른 아키텍처는 지원되지 않습니다.
이 프로젝트는 Macbook Air M1에서 실행되는 Debian VM에서 개발되었으며, .devcontainer/ 설정을 사용하여 Debian x86_64 Github Codespace에서도 테스트되었습니다.

의존성 (Dependencies):

apt install build-essential liburing-dev
# gcc 14+ 설치가 필요할 수 있습니다
git submodule update --init

특이사항으로, Linux 시스템 헤더를 제외하고는 ELF 라이브러리에 대한 의존성이 없습니다. 비록 라이브러리를 사용했다면 코드가 더 깔끔해졌을 수도 있지만 말입니다.

빌드 (Building):

make

자동 통합 테스트 실행:

make test

또는 공유 주소 공간 (shared address space)에서 직접 작성한 프로그램 실행:

./buildout/server /tmp/mytest.sock &
./buildout/launcher /tmp/mytest.sock program1 arg1 arg2 &
./buildout/launcher /tmp/mytest.sock program2 arg3 arg4

프로젝트에 대한 정보는 개요 또는 구현을 읽거나, 기존 작업과의 비교를 읽어보세요. 또한 결론에 학습된 교훈들을 정리해 두었습니다.

기술적 한계 (Technical limitations)

• 각 threadproc는 자체적인 런타임 라이브러리 인스턴스 (libc)를 가지며, 하나의 threadproc에서 malloc()을 호출한 뒤 다른 threadproc에서 해당 메모리를 free()하려고 시도하지 않도록 주의해야 합니다.
• 대상 애플리케이션은 동적으로 로드되는 모든 객체와 마찬가지로

그 외에도 덜 직접적인 몇 가지 한계점들이 있습니다.
예를 들어, threadprocs는 실행된 바이너리를 반영하는 /proc/[pid]/comm 값을 가지지만, cmdline은 설정할 수 없습니다.
exec() 시스템 콜 (syscall) 또한 threadproc 체계를 "탈출"하게 되는데, 이는 아마 의도된 동작일 수 있으나 미묘한 문제를 일으킬 수 있습니다.

실질적인 한계 (Practical limitations)

저의 초기 구상은 threadprocs가 서로에게 std::unique_ptr를 전달하고, 중첩된 데이터(nested data)를 포함한 IPC를 지원하는 것이었습니다.
ABI 문제를 차치하더라도, 가장 큰 걸림돌은 threadproc 1이 포인터를 해제하고 threadproc 2가 이를 std::unique_ptr로 감싸더라도, 소멸자 (destructor)가 호출되어 메모리를 할당 해제 (de-allocate)해야 할 시점이 되면 threadproc 2가 이를 수행할 수 없다는 점입니다.

각 tproc에 대해 독립적인 libc, libstdc++, 그리고 rust libstd 인스턴스를 갖는 것은 실행되는 프로그램에 대한 기술적 의존성을 크게 줄여주지만, 동시에 한 threadproc이 다른 threadproc에 의해 할당된 메모리를 해제할 수 없음을 의미합니다.

사용자는 이러한 한계를 중심으로 애플리케이션을 설계하여, 메모리가 항상 이를 할당한 tproc으로 다시 전달되어 올바르게 해제될 수 있도록 보장할 수 있습니다.
저는 커스텀 unique_ptr 유사체 (analogue)를 통해 객체를 할당한 threadproc으로 자동으로 다시 전달하는 애플리케이션 프레임워크를 스케치해 보았습니다. tproc-actors를 참조하세요.

이는 흥미로운 방향이며 더 탐구할 수 있는 질문들을 던지지만, 진지한 소프트웨어를 위한 실용적인 모델이라고 생각하지는 않습니다.
Pthreads는 다소 정체된 추상화(abstraction)이지만, 수십 년간 이를 중심으로 형성된 툴링 (tooling)과 언어 발전의 이점을 누리고 있습니다.
아직 제가 완전히 결론을 내린 것은 아니며, 아마 미래에는 커스텀 할당자 (allocator), 고정 매핑 (fixed mappings) 등을 통해 공유 메모리 영역을 확장하는 방법을 탐구할 수도 있을 것입니다.

문서 (Docs)

• 개요 (Overview)
• 설계 및 구현 (Design and Implementation)
• 기존 방식과의 비교 (Comparison to existing approaches)
• 결론 및 교훈 (Conclusions and lessons learned)