2016년 출판된 가메출판사의 Advanced! 리눅스 시스템 네트워크 프로그래밍(김선영 저)을 공부 목적으로 정리한 것입니다.
Ch1 프로세스
1 프로세스
1.1 전통적인 프로세스 복제 방법
fork – 유닉스 계열에서 프로세스를 복제하는 전통적인 방법
프로세스 복제 이유 – Multitasking.
복제된 자식 프로세스에 복수개의 task를 일임, 부모 프로세스와 독립적으로 작동 – 복수 개의 CPU가 설치된 경우 뛰어난 응답성과 성능, BUT 프로세스끼리 데이터 통신 처리에 드는 비용이 클 시 성능 하락 가능.
=> 서로 독립적으로 작동 OR 프로세스 간 통신 비용으로 발생하는 단점 << 멀티 프로세싱 성능 향상 – 멀티 프로세스 구조 적합
=> 복제할 프로세스 개수 제한(통신 비용 총합 고려)
Shell은 명령어를 받아들이면 fork를 해 자식 프로세스를 만들고 바로 exec를 호출하여 /bin/ls 프로그램 이미지로 교체함 / inetd 또한 연달아 fork-exec를 호출함
1.2 확장된 프로세스 실행 방법
fork-exec를 대체하는 기능 필요 – WHY?
1) Fork가 부모 프로세스 복제 시 모든 정적 정보를 복제(부모 프로세스의 heap 메모리, 정적 메모리, IPC 자원 ID, 열린 파일, 시그널 마스크 등) BUT, fork–exec 연달아 호출 시 부모 프로세스의 열린 파일, IPC 자원을 쓰지 않는 경우가 다수 -> 쓰지 않는 자원 복제 -> 오버헤드 존재 -> 대형 시스템에서 큰 영향
2) Realtime processing이 중요한 서비스의 경우
=> posix_spawn – 부모 프로세스의 자원 중 6가지(열린 파일, 프로세스 그룹ID, 유저 및 그룹 ID, 시그널 마스크, 스케줄링)의 자원을 선택적 복제 및 관리 가능
2 fork
pid_t fork(void);
Return value :
0 - 자식 프로세스에게 리턴되는 값
양수 - 부모 프로세스에게 리턴됨, 자식 프로세스의 PID
-1 – error
=> 3가지 케이스에 대해 코딩해야 함(조건문 사용) / 분기문을 잘 작성하지 않으면 재귀적으로 fork하게 되어 문제 발생 가능성 UP
2.1 vfork와 성능 문제
Vfork는 페이지 테이블을 복제하지 않음 – exec가 호출될 때 페이지 테이블이 해제되기 때문(오버헤드 방지)
현재는 fork 또한 copy-on-write 기능을 도입해 페이지 테이블 복사를 미룸(부모와 자식 프로세스의 페이지 테이블이 달라지는 시점에 복제)
BUT 여전히 페이지 테이블 제외한 모든 정적 자원 그대로 복제되는 오버헤드 존재
=> posix_spawn 계열 함수가 추가됨
3 exec(3) 계열 함수
Exec 계열 함수는 현재 실행 중인 프로세스 이미지를 새로운 프로세스 이미지로 대체함 – 실행 코드는 교체되나 기본적인 PID, PPID, 파일기술자 등 프로세스 정보는 유지
1st parameter - 프로그램 파일의 절대경로/상대경로
파일명만 넣을 시 함수에 따라 현재 작업 디렉터리(parameter의 이름이 path일 경우) 또는 PATH 환경 변수에 등록된 디렉터리(parameter의 이름이 file일 경우)를 검색하여 실행 프로그램 찾음
2nd parameter – execl 계열은 variable parameter(NULL로 끝남), execv 계열은 array
이미지 교체 후엔 기존 코드가 실행되지 않음
3.1 상속되지 않는 파일기술자
*File descriptor란? Low level I/O의 file reference number
UNIX에서 모든 I/O 시스템 호출은 파일기술자를 통해 열려 있는 파일을 참조, 3번부터 할당됨
exec 호출 시 파일기술자의 상속을 막기 위해, FD_CLOEXEC 플래그(close-on-exec)를 사용해 fcntl 함수 호출 => 자식 프로세스가 쓰지 않는 파일이 복제되는 오버헤드를 피할 수 있음
3.2 system 함수
셸을 실행시켜 명령어 실행(fork-exec 간단히 구현한 형태)
System은 실행 명령어가 작동되는 동안 부모 프로세스 잠시 정지 / 자식 프로세스의 정지, 종료 상태를 통보해주는 시그널인 SIGCHLD 블록 / 종료 시그널 SIGINT, SIGQUIT 무시 => 무한 대기의 위험으로 권장하지 않음
'Study > 리눅스 시스템 네트워크 프로그래밍' 카테고리의 다른 글
파일처리 / 리눅스 시스템 네트워크 프로그래밍 (0) | 2018.10.23 |
---|