프로세스 자체가 다른 개체를 위한 실행 환경으로 동작할 수 있다. - 119p
프로세스 자체가 다른 개체를 위한 실행 환경으로 동작할 수 있다. Java 프로그래밍 환경이 좋은 예이다.
대부분의 상황에서 실행가능한 Java 프로그램은 Java 가상기계(JVM) 안에서 실행된다. JVM은 적재된 Java 코드를 해석하고 그 코드를 대신하여 원 기계어를 이용하여 행동을 취하는 프로세스로서 프로그램을 실행한다. 예를 들어 컴파일된 Java 프로그램 Program.class를 실행하기 위해 다음과 같이 명령을 입력할 것이다.
java Program
java 명령어는 JVM을 보통의 프로세스처럼 실행시키고, JVM은 java 프로그램 Program을 가상기계 안에서 실행한다.
백그라운드 프로세스와 서비스 on Android - 128p
시작부터 Android는 다중 태스킹을 지원하였고, 백그라운드로 실행될 수 있는 응용 프로그램의 유형에는 제한을 두지 않았다. 응용 프로그램이 백그라운드로 처리될 필요가 있는 경우, 응용프로그램은 서비스를 사용하면 된다.
서비스는 백그라운드 프로세스를 대신하여 실행되는 별도의 응용 구성 요소를 말한다.
스트리밍 오디오 응용프로그램을 생각해보자. 이 응용프로그램이 백그라운드로 이동한다고 하면, 백그라운드 응용프로그램을 대신하여 서비스가 계속해서 오디오 파일을 오디오 장치 드라이버로 보낸다. 사실 백그라운드 응용프로그램이 보류되더라도 서비스는 계속 실행하게 된다. 서비스는 사용자 인터페이스를 가지고 있지 않고 메모리 사용량이 적기 떄문에, 모바일 환경에서 다중 태스킹을 위한 효율적인 기법을 제공한다.
다중 프로세스 구조 on Chrome 브라우저 - 138p~139p
크롬 브라우저는 탭 형식의 브라우징을 지원한다. 이 방식의 문제점은 탭 중 하나의 웹 응용프로그램이라도 갑자기 고장 나면 다른 탭을 포함한 전체 프로세스도 갑자기 고장날 수 있다는 것인데, Chrome 브라우저는 다중 프로세스 구조를 활용하여 이 문제를 해결하게끔 설게 되었다.
Chrome은 브라우저, 렌더러, 플러그인의 세 유형의 프로세스를 구분한다.
브라우저
브라우저 프로세스는 사용자 인터페이스와 함께 디스크와 네트워크 입출력을 관리하는 책임을 진다. Chrome이 시작될 때 새로운 브라우저 프로세스가 생성된다. 오직 하나의 브라우저 프로세스만이 생성된다.
렌더러
렌더러 프로세스는 웹 페이지를 표시하기 위한 프로그램 로직을 포함한다. 따라서 HTML,Javacript,이미지 등을 처리하기 위한 프로그램 로직을 포함한다. 일반적으로 새 탭에서 열린 웹 사이트 마다 새로운 렌더러 프로세스가 생성되고, 여러 렌더러 프로세스가 동시에 활동하게 된다.
플러그인
플러그인 프로세스는 Flash 또는 QuickTime과 같이 사용중인 플러그인 종류마다 생성된다. 플러그인 프로세스는 플러그인을 위한 코드 뿐 아니라 플러그인이 연관된 렌더러 프로세스와 브라우저 프로세스와 통신할수 있게 하는 코드를 포함하고 있다.
다중 프로세스 방식의 이점은 만일 한 탭의 웹사이트가 고장나면 오직 해당 탭의 렌더러 프로세스만 영향을 받고 나머지 탭의 렌더러 프로세스는 영향을 받지 않는다는 것이다. 게다가 렌더러 프로세스는 샌드박스 안에서 실행되는데, 이는 보안 취약점의 영향을 최소화하기 위해 디스크와 네트워크 입출력에 대한 접근이 제한된다는 것을 의미한다.
프로세스 간 통신 - 공유메모리, 메시지 전달 - 137~142p:
(a) 공유 메모리(shared memory)
공유 메모리 모델에서는 협력 프로세스 들에 의해 공유되는 메모리의 영역이 구축된다. 프로세스들은 그 영역에 데이터를 읽고 쓰고 함으로써 정보를 교환할 수 있다.
일반적으로 운영체제는 한 프로세스가 다른 프로세스의 메모리에 접근하는 것을 금지한다는 것을 기억하자. 공유 메모리는 둘 이상의 프로세스가 이 제약 조건을 제거하는 것에 동의하는 것을 필요로 한다.
또한 데이터의 생산자와 소비자가 서로 충돌하지 않도록 해야한다.(Producer-Consumer 패러다임)
(b) 메시지 전달(message passing)
메시지 전달 모델에서는 통신이 협력 프로세스들 사이에 교환되는 메시지를 통해 이루어진다.
메시지 전달 방식은 공유메모리처럼 동일한 주소 공간을 공유하지 않고도 프로세스들이 통신을 하고 그들의 동작을 동기화 할 수 있도록 허용하는 기법을 제공한다. 메시지 전달 모델은 충돌을 회피할 필요가 없기 때문에 적은 양의 데이터를 교환하는데 유리하다.
메시지 전달 방식은 통신하는 프로세스들이 네트워크에 의해 연결된 다른 컴퓨터들에 존재할 수 있는 분산 환경에서 특히 유용하다. 또한 분산 시스템에서 공유메모리 모델보다 구현하기 쉽다.
클라이언트-서버 통신 with Socket - 162~164p
일반적으로 소켓은 클라이언트-서버 구조를 사용한다. 서버는 지정된 포트에 클라이언트 요청 메시지가 오기를 기다리게 된다. 요청이 수신되면 서버는 클라이언트 소켓으로부터 연결요청을 수락함으로써 연결이 완성된다.
Telnet, ftp, 및 http 등의 특정 서비스를 구현하는 서버는 well-known 포트로부터 메시지를기다린다.(1024번 미만의 모든 포트는 well-known포트로 간주되며 표준 서비스를 구현하는데 사용된다.)
클라이언트 프로세스가 연결을 요청하면 호스트 컴퓨터가 포트 번호를 부여한다. 이 번호는 1024보다 큰 임의의 정수가 된다. 예를 들어 호스트 X(IP: 146.86.5.20)에 있는 클라이언트 프로세스가 웹 서버(IP: 161.25.19.8)에 접속하려고 한다면 호스트X는 클라이언트 프로세스에게 포트 1625를 부여한다.(웹서버는 포트 80을 listen하고 있다.) 연결은 이 두 개의 소켓 호스트X의 (146.86.5.20:1625)와 웹 서버의(161.25.19.8:80)으로 구성된다.
모든 연결은 유일해야 한다. 따라서 호스트 X에 있는 다른 클라이언트 프로세스가 위와 동일한 웹 서버와 통신을 하면 그 클라이언트는 1024보다는 크고 1625가 아닌 다른 포트 번호를 부여받게 된다. 이것은 모든 연결이 유일한 소켓 쌍으로 구성되는 것을 보장한다.
소켓을 이용한 통신은 분산된 프로세스 간에 널리 사용되고 효율적이기는 하지만 너무 낮은 수준이다. 우선 소켓은 스레드 간에 구조화되지 않은 바이트 스트림만을 통신하도록 하기 때문이다. 이러한 원시적인 바이트 스트림 데이터를 구조화하여 해석하는 것은 클라이언트와 서버의 책임이 된다. 이에 대한 대안으로 더욱 높은 수준의 통신 기법인 원격 프로시저 호출(RPC)이 있다.
클라이언트-서버 통신 with RPC, Remote Procedure Calls -164~167p
RPC 통신에서 전달되는 메시지는 구조화 되어있고 , 따라서 데이터의 패킷 수준을 넘어서게 된다. 각 메시지에는 원격지 포트에서 listen중인 RPC 디먼의 주소가 지정되어 있고, 실행되어야 할 함수의 식별자, 그리고 그 함수에게 전달되야할 매개변수가 포함된다.
즉, RPC는 다른 컴퓨터에 있는 프로세스에서 함수를 호출할 수 있는 방식으로 함수(프로시저) 호출 개념을 추상화 한다.
RPC는 매개변수 정돈(parameter marshalling)을 통해 클라이언트와 서버 기기의 데이터 표현 방식의 차이 문제를 해결한다(ex. big-endian vs little-endian). 데이터 표현 방식의 차이 문제를 해결하기 위해 대부분의 RPC 시스템은 기종중립적인 데이터 표현 방식을 정의한다. 이 중 하나가 XDR이다. 클라이언트와 서버 모두 XDR 형식으로 데이터를 주고받는다.
또, RPC는 네트워크 오류로 인해 메시지 전송이 실패하거나 메시지가 중복되어 여러번 실행되는 문제를 해결하기 위해 메시지가 정확히 한번 처리 되도록 보장한다.
