Process / thread architecture
Processes
크로미움은 멀티프로세스 구조를 가지고 있습니다. 하나의 브라우저 프로세스와 N개의 샌드박스 렌더러 프로세스를 가집니다. 블링크는 하나의 렌더러 프로세스를 실행합니다.
얼마나 많은 렌더러 프로세스가 생성될까요? 보안상의 이유로, 여러 사이트의 문서들 간의 메모리 주소 영역은 서로 격리되어 있어야 합니다(이것을 Site Isolation이라고 합니다). 개념적으로는 각 렌더러 프로세스는 하나의 사이트만을 전담하여야 하지만, 현실적으로 사용자가 너무 많은 탭을 열거나 장치의 메인 메모리가 부족하면 이런 제약을 지키기는 어렵습니다. 이런 경우, 하나의 렌더러 프로세스는 다중 iframe들이나 서로 다른 사이트를 연 여러 탭들 간에 공유될 수도 있습니다. 이 말은, 하나의 탭안에 있는 여러 iframe이 서로 다른 여러 렌더러 프로세스에 의해 그려질 수도 있으며, 여러 탭안에 있는 여러 iframe이 동일한 하나의 렌더러 프로세스에 의해 그려질 수도 있다는 뜻입니다. 즉, 렌더러 프로세스와 iframe 및 탭은 1:1 매핑되지 않습니다.
렌더러 프로세스가 샌드박스 안에서 실행된다면, 블링크는 시스템 콜(예, 파일접근, 소리재생)의 실행과 사용자 프로파일 데이터(예, 쿠키, 비밀번호)에 대한 접근을 브라우저 프로세스에게 요청할 필요성이 있습니다. 이 브라우저-렌더러 간 프로세스 통신은 Mojo(모조)를 통해서 이루어집니다. (참고: 과거에는 Chromium IPC를 사용했고, 아직도 여러 곳에서 사용하고 있긴 하지만, 어쨌건 내부적으로는 모조를 사용합니다.) 크로미움 측면에서 보면, 서비스화는 진행 중이며, 브라우저 프로세스는 “서비스”들의 집합으로 추상화되고 있습니다. 블링크 관점에서 보면, 블링크는 모조를 이용해서만 서비스 및 브라우저 프로세스와 상호 작용할 수 있습니다.
If you want to learn more:
- 멀티프로세스 구조
- 블링크에서의 Mojo 프로그래밍: platform/mojo/MojoProgrammingInBlink.md
Threads
하나의 렌더러 프로세스에서 얼마나 많은 쓰레드가 생성될까요?
블링크는 하나의 메인 쓰레드와 N 개의 워커 쓰레드 그리고 몇 개의 내부 쓰레드를 가집니다.
거의 모든 중요한 일은 이 메인 쓰레드에서 일어납니다. 모든 자바스크립트(워커들을 제외한), DOM, CSS, 스타일과 레이아웃 계산은 이 메인 쓰레드에서 실행됩니다. 블링크는 주로 단일 쓰레드 구조를 전제로 하여 메인 쓰레드 성능의 극대화를 위해 고도로 최적화되었습니다.
블링크는 웹워커, 서비스워커, Worklets을 실행하기 위해 다중 워커 쓰레드를 생성할 수도 있습니다.
블링크와 V8은 웹오디오, 데이터베이스, GC 등을 다루기 위해서 몇 개의 내부 쓰레드를 생성할 수도 있습니다.
쓰레드간 통신을 위해, PostTask API를 이용하여 메시지를 전달해야 합니다. 공유메모리 프로그래밍은 성능상의 이유로 꼭 필요로 하는 몇 군데를 제외하고는 권장되지 않습니다. 이것이 블링크 코드 기반에서는 MutexLocks를 많이 볼 수 없는 이유입니다.
If you want to learn more:
- Thread programming in Blink: platform/wtf/ThreadProgrammingInBlink.md
- Workers: core/workers/README.md
Initialization & finalization of Blink
블링크는 BlinkInitializer::Initialize()를 통해 초기화를 합니다. 이 메서드는 블링크 코드가 실행되기 전에 반드시 호출되어야 합니다.
반면에, 블링크는 마무리 과정이 없습니다. 즉, 렌더러 프로세스는 클린업 과정 없이 강제로 종료됩니다. 첫번째 이유는 성능 때문입니다. 다른 일반적이 이유는, 렌더러 프로세스에서 모든 것을 정돈된 방식으로 클린업하는 것은 너무나 어렵기 때문입니다(그리고 그럴만한 가치가 없습니다).
