다시 시작하는 TIL 25일차

오늘 한일

오늘 버전관리와 저장의 필요성을 제대로 느꼈다.

 

평소에 저장안하고 잠자기 모드로만 사용했는데 OS 자동업데이트 때문에 대략 2주간 짰던 코드가 통쨰로 날아갔다.

 

이미 짜봤던거라 다시 짜고 있는데 그냥 현타가 아주 쌔게 온다.

 

복구하는데 한 3~4일 정도 걸릴 거 같다.

 

다시 짜는김에 좀 더 깔끔하게 짜봐야곘다.

 

퇴근 후 공부

우리가 아는 프로세스는 계층적 구조를 가지는데 , 부모 프로세스가 있으면 자식 프로세스가 존재한다.

프로세스가 종료될 때 종료코드는 운영체제로 전해지는데 운영체제는 이 종료코드를 받고 메모리 공간을 남겨둔다.

남겨 두는 이유는 부모 프로세스가 자식 프로세스가 반환한 값을 요청해 자식 으로부터 그 값을 획득했을 때 비로소 자식 프로세스를 종료시킨다.

또 그러면 왜 부모 프로세스는 자식 프로세스에게 관심을 가지고 확인을 할까? 

자식 프로세스에게 특정 일을 시켰는데 종료된 코드를 통해 확인하고 수행할 작업이 있다면 저런 구조를 가진게 이해가 간다.

빈대로 부모 프로세스가 자식 프로세스 반환 값의 관심이 없다면 종료는 시켰지만 자원을 회수하지 않게 된다. 이를  좀비 프로세스라고 하는것이다.

좀비 프로세스의 예방은 반환값을 가져와서 처리해야한다.

좀비 프로세스란

 

- 실행이 완료되었음에도 불구하고, 소멸되지 않은 프로세스
- 프로세스도 main함수가 반환되면 소멸되어야 한다.
- 소멸되지 않았다는 것은 프로세스가 사용한 리소스가 메모리 공간에 여전히 존재한다는 의미이다.

 

좀비 프로세스의 생성원인

- 자식 프로세스가 종료되면서 반환하는 상태 값이 부모 프로세스에게 전달되지 않으면 해당 프로세스는 소멸되지 않고 좀비가 된다.

- 인자를 전달하면서 exit를 호출하는 경우
- main 함수에서 return문을 실행하면서 값을 반환하는 경우

 

보통 옛날 레거시 코드에서는 wait 함수를 많이 사용했는데 wait 함수의 경우 자식 프로세스가 종료되지 않은 상황에서는 반환하지 않고 블로킹 상태에 놓인다는 특징이 있다.

그래서 블로킹 상태에 놓이지 않게끔 하는 waitpid 함수가 존재한다.

 

pid_t waitpid(pid_t pid,int p_ statloc, int options);

성공 시 종료된 자식 프로세스의 ID, 실패시 -1 반환된다.

pid = 종료를 확인하고자 하는 자식 프로세스의 ID 전달 이를 대신해서 -1을 전달하면 wait함수와 마찬가지로 임의의 자식 프로세스가 종료되기를 기다림.

statloc = wait 함수의 매개변수 statloc과 동일한 의미로 사용된다.

options = 헤더 파일 sys/wait.h 선언된 상수 WNOHANG을 인자로 전달하면, 종료된 자식 프로세스가 존재하지 않아도 블로킹 상태에 있지 않고 , 0 을 반환하면서 빠져 나온다.