이 중에서 이전에 자주 사용했던 open, close, read, write, malloc, free는 소개를 생략할 것이다. 또한 perror, strerror, exit에 대해서는 miniRT 과제를 소개할 때 이미 알아본 적이 있다. 따라서 perror, strerror, exit에 대해서는 아래 링크의 External Functions를 참고하자.

miniRT

정적 라이브러리 특정 기능을 하는 라이브러리를 정적 (static)으로 생성한다는 것은 실행 파일을 만드는 Link 단계에서 라이브러리를 포함시키겠다는 것을 의미한다. 따라서 라이브러리 내부의 코드가 이를 사용하는 실행 파일에 함께 포함되기 때문에, 별도의 작업 없이 실행 파일만으로 라이브러리 내부의 코드를 이용할 수 있게 된다.

https://bigpel66.oopy.io/library/42/inner-circle/5

이번 글에서는 access, unlink, fork, wait, waitpid, dup, dup2, pipe, execve만을 알아볼 것이다. 설명된 내용에는 Error에 대한 얘기가 종종 나온다. 따라서 위 링크의 Error에 대한 내용을 꼭 먼저 읽고 오길 바란다. 링크의 글이 너무 길다면 적어도 errno에 대해서라도 이해하는 것을 권한다.

1) access

1. 의존성

#include <unistd.h>
C
복사

2. 함수 원형

int access(const char *path, int mode);
C
복사

3. 함수 설명

access 함수는 path에 해당하는 파일을 mode에 따라서 확인을 하게 된다. path에는 일반 파일 외에 심볼릭 링크, 디렉토리 등을 포함하여 모든 파일을 인자로 사용할 수 있다. mode는 <unistd.h>에 매크로를 통해 값들이 정의되어 있다. access 함수는 인자로 받은 mode에 만족하면 0을 반환하고, 그렇지 않으면 -1을 반환한다.

위 그림에서 볼 수 있듯이, mode를 통해서 파일의 존재 유무 및 파일의 권한을 확인할 수 있다. mode로 주어진 값들은 비트를 쉬프트 한 값들로 정의되었기 때문에 Mask로써 이용될 수 있다. 따라서 파일의 존재 유무와 동시에 파일의 실행 권한이 있는지 동시에 확인하고 싶다면, | 라는 OR 비트 연산을 이용하여 한 번에 검사하는 것이 가능하다. 예를 들어, mode = F_OK | X_OK;와 같이 두고 access 함수의 인자로 mode를 주게 되면 파일의 존재 유무와 파일의 실행 권한을 동시에 확인할 수 있다. 단, |를 통해 동시에 검사하려는 조건들 중에 하나라도 만족하지 않는다면 반환 값으로 -1을 받게 되므로, |는 여러 조건을 동시에 만족해야 하는 경우에만 사용하도록 한다.

cd, exit과 같이 Shell의 Built-In 명령어를 제외하고, 파일로 유지 되는 명령어들을 exec 계열의 함수를 이용하여 실행하기 전에 access 함수를 통해 선행적으로 파일에 대한 검사를 수행할 수 있다.

4. 예시

#include <stdio.h>
#include <unistd.h>

int	main(void)
{
	int	mode;

	mode = 0;
	mode |= F_OK;
	if (!access("test.txt", mode))
		printf("File is existing\n");
	else
		printf("File is not existing\n");
	mode &= 0;
	mode |= X_OK;
	if (!access("test.txt", mode))
		printf("File is executable\n");
	else
		printf("File is not executable\n");
	return (0);
}
C
복사

2) unlink

1. 의존성

#include <unistd.h>
C
복사

2. 함수 원형

int unlink(const char *path);
C
복사

3. 함수 설명

unlink 함수는 파일을 삭제할 때 사용된다. 간단하게는 파일의 삭제이지만, 정확하게는 하드 링크를 끊는데 이용된다. 따라서 unlink 함수를 이해하기 전에 하드 링크와 심볼릭 링크에 대해서 이해할 필요가 있다.

일반적으로 말하는 파일은 실제로 디스크 상에 위치한 데이터에 불과하다. 즉, 파일을 생성하고 삭제한다는 개념은 디스크 상에 데이터를 생성하고 삭제한다는 것과 일맥상통하다. 그리고 파일이라고 불리는 이 데이터들은 유닉스 계열의 운영체제에서 모두 inode로 관리된다. inode에는 파일의 권한, 형태, 고유 번호, 소유자 및 그룹, 원본 데이터의 주소 등 파일에 대한 모든 것들이 기록되어 있다. 이에 대해선 위 그림을 통해 조금 더 정확히 이해할 수 있다. 즉, inode를 통해 데이터들을 보다 쉽게 조작하고 관리할 수 있다는 것이다. 이 때 사용자는 데이터를 실행하거나 읽고 쓰는 등 조작을 하고자 한다면, 하드 링크를 이용하여 inode에 접근하고 원하는 작업을 수행하게 된다. 즉, 일반적으로 사용자 공간에서 확인할 수 있는 파일들은 모두 하드 링크라고 볼 수 있다.

위에서 확인한 것처럼 기본적으로 파일이 존재한다는 것은 디스크 상에 데이터가 존재하는 것이고, 이에 대한 inode가 무조건 존재함과 동시에 inode에 접근할 수 있는 하드 링크를 적어도 하나 이상 가지고 있는 것을 의미한다. 만일 inode에 접근할 수 있는 하드 링크가 하나도 없게 되면, 이것이 곧 파일의 삭제로 이어진다.

그렇다면 기존에 존재하고 있는 하드 링크에 ln 명령어를 이용하면 어떻게 될까? 하나의 파일이 추가적으로 생성되는 것을 볼 수 있는데, 사용자가 보기에는 별도의 파일이 생성된 것처럼 보이지만 실제로는 동일한 inode를 가리키는 하드 링크에 불과하다. 데이터를 참조하고 있는 inode는 고유하고, 하드 링크들이 몇 개가 있든 위의 그림과 같이 모두 동일한 inode를 참조하게 된다. 실제로 디스크 상에 존재하는 데이터를 수정하게 되면, 모든 하드 링크들이 영향을 받는 이유가 이 때문이다. 그리고 동일한 inode를 참조하고 있는 하드 링크가 다수 존재하여도 크기는 고유하게 점유된다. 하드 링크의 대표적인 예는 현재 디렉토리를 의미하는 .와 상위 디렉토리를 의미하는 ..이 있다.

심볼릭 링크는 ln 명령어의 -s 옵션을 이용하여 생성할 수 있는데, 이를 이용하면 하드 링크와 동일하게 파일이 추가적으로 생성되는 것을 볼 수 있다. 하지만 inode를 조사해보면 하드 링크와는 달리 별도의 inode를 참조하는 것을 확인할 수 있다. 즉, 심볼릭 링크를 통해 생성된 파일은 하드 링크와 달리 하드 링크에 대한 inode를 참조하지 않는다. 이와 같은 상황을 위 그림을 통해서 알 수 있듯이, 심볼릭 링크는 별도의 inode를 갖고 있고 디스크 상에 별도의 데이터를 유지하고 있으며 디스크 상의 데이터는 그저 하드 링크의 inode를 참조하도록 주소만을 가지고 있을 뿐이다. 이 때문에 심볼릭 링크가 바로 가기와 같이 작동할 수 있으며 하드 링크와 달리 별도의 크기를 갖는 것이다. 심볼릭 링크로 생성된 파일은 어떤 하드 링크를 참조하는 포인터 링크이면서, 동시에 하나의 하드 링크이다.

위에서 unlink 함수는 하드 링크를 끊는데 이용된다고 했는데, 이는 하드 링크의 이름을 삭제하면서 inode를 참조하고 있는 하나의 하드 링크를 끊는 것이다. 예를 들어 위 그림과 같이 사용자의 공간에 a, b, c가 있고, 3개의 하드 링크는 모두 동일한 inode를 참조하고 있다고 해보자. 만약 unlink의 path 인자로 a라는 하드 링크를 주게 되면, 사용자의 공간에서 a는 삭제되지만 여전히 그 파일은 존재하고 있다. 즉, 사용자가 보았을 때는 파일을 삭제하는 것처럼 보이지만 파일을 완전히 삭제하기 위해선 inode를 참조하는 모든 하드 링크를 끊어야만 비로소 파일이 삭제된다. 이와 같은 동작은 유닉스의 rm 명령어와 동일하다. rm 명령어의 대상이 일반 파일이라면 이는 unlink 함수와 동일하게 작동하고, 대상이 디렉토리라면 이는 rmdir 명령어와 동일하게 작동한다.

파일의 삭제라는 개념과 하드 링크를 끊는다는 것에 대한 정확한 차이를 이해하기 위해 설명이 길었는데, 여튼 사용자가 보기에는 unlink의 동작이 곧 사용자 공간에 존재하는 파일의 삭제와 동일하다고 볼 수 있다. unlink의 반환 값이 0이라면 정상적으로 하드 링크를 끊은 것이고, 정상적으로 동작하지 못했을 때는 -1이 반환된다.

4. 예시

#include <stdio.h>
#include <unistd.h>

int	main(int argc, char **argv)
{
	int	i;

	i = 0;
	while (++i < argc)
	{
		if (!access(argv[i], F_OK))
		{
			if (!unlink(argv[i]))
				printf("File is unlinked\n");
			else
				printf("File is not unlinked\n");
		}
		else
			printf("File is not existing\n");
	}
	return (0);
}
C
복사

3) fork

1. 의존성

#include <unistd.h>
C
복사

2. 함수 원형

pid_t fork(void);
C
복사

3. 함수 설명

현재 실행 중인 프로세스에서 자식 프로세스를 생성한다. 이에 따라 현재 실행 중인 프로세스는 자식 프로세스를 갖고 있는 부모 프로세스가 된다. 생성된 자식 프로세스는 부모 프로세스와 완전히 똑같은 형태로 생성이 되는데, 이는 곧 부모 프로세스의 메모리의 상태를 그대로 갖는다는 것을 의미한다. 즉, 부모 프로세스의 메모리 주소 공간을 일괄적으로 복사하여 이를 자식 프로세스에게 할당하게 되고, PC (Program Counter) 역시 복사되어 자식 프로세스는 fork 함수 호출 이후부터 Context를 갖게 된다.

PC (Program Counter)? PC 라는 것은 CPU와 같은 중앙 처리 장치 내부의 레지스터 중에 하나로써 현재 처리 중인 Instruction의 바로 다음 Instruction의 주소를 갖고 있다. 즉, 실행될 Instruction의 위치를 알고 있기 때문에 Instruction Pointer 라고 불리기도 한다. 여기서 말하는 Instruction이란 C 언어의 코드 한 줄을 말하는 것이 아니라, 기계적으로 처리되는 기계어 한 구문을 말한다. 위의 fork를 예로 들면, fork를 처리하는데 요구되는 기계어 묶음이 있을텐데 이를 마치게 되면 PC는 fork 다음에 실행될 구문의 첫 기계어의 위치를 갖고 있게 된다. 자식 프로세스는 PC 역시 복사하여 생성되기 때문에 PC가 갖고 있는 주소에 해당하는 Instruction부터 Fetch하여 실행한다.

이처럼 자식 프로세스를 갖게 되었을 때 fork의 반환 값으로 부모 프로세스에게 할당되는 값과 자식 프로세스에게 할당되는 값이 서로 다르다. 부모 프로세스에는 자식 프로세스의 pid 값이 fork의 반환 값으로 설정되고, 자식 프로세스에는 0이라는 값이 fork의 반환 값으로 설정된다. 만일 부모 프로세스에서 fork를 수행했을 때 정상적으로 fork가 되지 않는다면 -1이 반환된다. 따라서 이에 대한 에러 처리를 별도로 해주어야 한다.

4. 예시

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int	global;

int	main(void)
{
	int		automatic;
	int		*heap;
	pid_t	pid;

	global = 10;
	automatic = 10;
	heap = (int *)malloc(sizeof(int));
	if (!heap)
		return (1);
	*heap = 10;
	pid = fork();
	if (pid == -1)
	{
		free(heap);
		return (1);
	}
	else if (!pid)
	{
		printf("Child: Before operations -> %d (Global), %d (Automatic), %d (Heap)\n", global, automatic, *heap);
		global += 10;
		automatic += 10;
		*heap += 10;
		printf("Child: After operations -> %d (Global), %d (Automatic), %d (Heap)\n", global, automatic, *heap);
	}
	else if (pid)
	{
		printf("Parent: Before operations -> %d (Global), %d (Automatic), %d (Heap)\n", global, automatic, *heap);
		global += 20;
		automatic += 20;
		*heap += 20;
		printf("Parent: After operations -> %d (Global), %d (Automatic), %d (Heap)\n", global, automatic, *heap);
	}
	free(heap);
	return (0);
}
C
복사

자식 프로세스와 부모 프로세스의 메모리 공간이 별도로 구성된다는 것은 위와 같은 코드를 실행함으로써 쉽게 알 수 있다. 메모리 공간이 별도이므로 자식 프로세스에서의 증감 연산 결과와 부모 프로세스에서의 증감 연산의 결과가 다른 것을 주어진 그림처럼 확인할 수 있다.

애초에 프로세스가 운영체제로부터 할당받은 메모리는 Shared Memory 기법을 사용하지 않는 이상 다른 프로세스와 공유될 수 없는 독립성을 보장받기 때문에 별도의 공간이라는 것을 증명하기 위해 굳이 위와 같은 실험을 하지 않아도 된다.

#include <stdio.h>
#include <unistd.h>

int main(void)
{
	pid_t pid;

	pid = fork();
	if (pid == -1)
		return (1);
	else if (!pid)
	{
		printf("Child: I got a pid %d internally\n", pid);
		usleep(100000);
		printf("Child: Exiting with Code 0\n");
	}
	else if (pid)
	{
		printf("Parent: I have a Child which pid is %d\n", pid);
		printf("Parent: Exiting with Code 0\n");
	}
	return (0);
}
C
복사

주어진 예시를 실행해보면, usleep으로 0.1초간 자식 프로세스를 Sleep 상태로 만들기 때문에 부모 프로세스가 먼저 종료하는 것을 볼 수 있다. 쉘 자체에서 실행된 프로세스는 부모 프로세스이기 때문에 부모 프로세스의 종료만 기다리게 되고, 부모 프로세스의 종료와 동시에 쉘은 새로운 프롬프트를 출력시키는 것을 볼 수 있다. 따라서 프로그램이 마친 뒤에 뒤늦게 자식 프로세스가 출력한 구문이 새로운 프롬프트 이후에 나타나게 된다. 자식 프로세스의 작업을 마칠 때까지 부모 프로세스가 이를 기다리게 하기 위해선 wait 혹은 waitpid를 이용해야 한다. 이와 같은 함수들을 통해 멀티 프로세싱 프로그램에 대해 보다 심도 있게 이해할 수 있다. 이어지는 항목에서 wait 함수부터 이해해보자.

4) wait

1. 의존성

#include <sys/wait.h>
C
복사

2. 함수 원형

pid_t wait(int *status);
C
복사

3. 함수 설명

wait 함수는 자식 프로세스의 종료를 부모 프로세스에서 기다린다는 개념으로 간단히 이해할 수 있다. 이전 fork 함수의 예제를 보면 자식 프로세스는 0.1초동안 Sleep 상태가 되어 부모 프로세스가 먼저 종료되었는데, 이 때 자식 프로세스의 ppid는 1이 되면서 고아 프로세스가 된다. 이와 같은 현상을 방지할 때 사용되는 것이 wait 함수이다. wait 함수를 이용하게 되면 부모 프로세스는 자식 프로세스가 종료될 때까지 Sleep 상태로 기다리게 되며, 자식 프로세스가 종료되었을 때 비로소 wait 함수 이후의 구문을 부모 프로세스가 처리할 수 있게 된다. 그렇다면 자식 프로세스를 기다리지 않아도 되는 상황에서는 wait 함수를 쓰지 않아도 되는 것일까? 이에 대한 답을 아래의 예시에서 찾아볼 것이다. 그 전에 wait 함수의 시그니처에 대해서 먼저 알아보자.

자식 프로세스가 main문의 return 혹은 exit을 통해 명시된 종료 코드에 의해서 (정상 종료든 비정상 종료든) 종료되면 wait 함수의 반환 값은 자식 프로세스의 pid가 되고, 그렇지 않고 자식 프로세스가 시그널에 의해 종료되면 errno가 EINTR로 설정되면서 -1을 반환한다. 이 때 wait 함수의 인자로 받은 status는 자식 프로세스가 종료되면서 반환한 다양한 정보들을 기록하게 된다. 자식 프로세스와 부모 프로세스의 메모리 공간이 별도로 유지되기 때문에 status라는 인자는 자식 프로세스에게 넘어가서 기록되는 것이 아니라 말 그대로 자식 프로세스가 종료되면서 넘긴 정보들을 부모 프로세스가 취하면서 자식 프로세스의 종료 시점에 기록되는 것이다. wait 함수에서 사용되는 status는 waitpid에서 사용되는 status와 동일하므로 조금 구구절절하더라도 짚고 넘어가보자.

pid_t는 Mac OS X와 같은 Darwin 운영체제에서 __darwin_id_t로 Alias되어 있다. pid_t뿐만 아니라 uid_t, gid_t와 같은 타입들도 이에 해당되며, __darwin_id_t는 __uint32_t이다.

status에 기록되는 정보들은 종료 코드와 시그널이다. 여러 정보가 하나의 변수에 기록되었다는 것은 비트를 이용하여 기록되었다는 것이므로, 이와 같은 정보를 각각 회수하기 위해선 별도의 마스킹 작업이 필요하다. 따라서 각 정보들이 얼만큼의 비트를 이용했는지 정확히 하기 위해서 <sys/wait.h>를 확인할 필요가 있다. 위 그림을 보면 status에 기록된 정보들을 확인할 수 있도록 매크로를 통해 정의된 것을 볼 수 있는데, 내용을 놓치지 않도록 찬찬히 짚어보자.

위 코드를 얼핏 보았을 때 주로 이용되는 비트 연산은 8개의 비트를 쉬프팅 하는 연산이며, 이 때 비교는 단 1바이트만을 수행하는 것을 알 수 있다. 해당 연산이 무엇을 위한 것인지는 아직까지 알 수 없지만, int 값의 status를 이용했을 때 기록 자체는 2바이트 내에서 이뤄진다는 것을 유추할 수 있다. (쉬프팅 했을 때 1바이트이므로 기존 1바이트까지 총 2바이트가 된다.) 이용되는 공간이 2바이트임에도 status가 int로 이용되는 이유는 곧 알게 된다.

바이트 값이 갖고 있는 정보에 대해 위 그림을 이용하여 풀어보면, status의 4바이트 중에서 2번 index의 바이트는 종료 코드를 의미하고 3번 index의 바이트는 시그널을 의미한다. 즉, 종료 코드와 시그널을 조합한 값이 곧 status가 되는데 이 때 이용하는 연산이 W_EXITCODE라는 매크로 함수이다. 자식 프로세스가 종료되면 W_EXITCODE를 이용하여 부모 프로세스의 status를 기록하게 되고, W_EXITCODE는 유닉스 설계 상 int 타입으로 이용하도록 되어 있다. 따라서 2바이트만을 이용함에도 status가 int로 이용되는 것이다.

www.freepascal.org

https://www.freepascal.org/docs-html/rtl/unix/w_exitcode.html

종료 코드 및 시그널에 대한 기록의 분기는 위 그림과 같이 나타난다. 반환 값에 대해 설명할 때 살짝 언급한대로 종료 코드에 의한 종료인지, 시그널에 의한 종료인지가 status 기록에 영향을 끼치게 된다. 종료 코드에 의한 종료가 발생했을 때의 status를 알아본 뒤 시그널에 의한 종료가 발생했을 때의 status를 알아보도록 하자.

일반적으로 프로세스가 정상적이든 비정상적이든 시그널 없이 종료를 하게 되면, 종료 코드가 2번 index의 바이트가 기록되고 3번 index의 바이트는 시그널이 없으므로 0으로 채워지게 된다. 정상 종료를 의미하는 0을 자식 프로세스가 반환하게 되면, 부모 프로세스에서는 종료 코드도 0이고 시그널도 0이므로 status 값은 0이 된다. 반대로 비정상 종료를 의미하는 0 이외의 값을 자식 프로세스가 반환하게 되면, status 값이 비정상적으로 큰 값이 나오는 것을 확인할 수 있는데 이는 3번 index의 바이트가 0으로 채워져 있는 것을 고려하지 않아서 그렇다. 0 이외의 종료 코드를 받았을 때 이를 정확하게 취득하기 위해선 시그널에 대한 정보를 배제해야하므로, 8개의 비트를 오른쪽으로 쉬프팅 한 후 정확히 최하위 8개의 비트를 취득하면 된다.

명시된 종료 코드에 의한 종료

만일 프로세스가 시그널에 의해서 종료를 하게 되면, 이는 크게 STOP 시그널에 의한 종료인지 이를 제외한 시그널에 의한 종료인지에 따라 나뉘게 된다. STOP 시그널에 의한 종료인 경우에는 CONT 시그널을 통해 STOP 시점부터 이어서 실행할 수 있지만 그 외의 시그널은 그렇지 않다는 점에서 차이가 있다.

우선 STOP 시그널과 CONT 시그널은 다른 시그널들과 달리 자기 자신에게 해당되는 시그널 번호를 사용하더라도 내부적으로 3번 index의 바이트 값이 127로 고정된다. 이 때 종료 코드가 기록되는 2번 index의 바이트가 곧 자기 자신에게 해당되는 시그널 번호로 채워진다. CONT 시그널을 보내는 경우에는 SIGCONT에 해당하는 19가 채워지고, STOP 시그널을 보내는 경우에는 SIGSTOP에 해당하는 17이 채워지게 된다. STOP 시그널에 해당하는 17과 CONT 시그널에 해당하는 19을 3번 index의 바이트에 이용하면 편할텐데, 그렇게 하지 않는 이유는 두 시그널이 유기적으로 연결되어 있기 때문에 스위치의 on/off처럼 동작하도록 만들기 위함이다. 하나의 특정한 값을 정해두고 처리하게 되면 프로그램 입장에서는 더 편해진다. (Mac OS X의 시그널은 유닉스의 시그널을 따른다. 시스템 마다 시그널이 다를 수 있으므로 이에 유의하자.)

시그널에 해당하는 번호를 이용하면 어떤 시그널인지 각각 비교를 해야하지만, 두 동작 자체가 유기적으로 연결되어 있으므로 동일한 값을 이용하면 한 번의 비교만으로 편하게 처리가 가능하다. 현재 프로세스의 상태는 프로그램의 내부에서 처리하지 않아도 그 상태를 알 수 있다.

시그널에 의한 종료 (STOP 시그널 및 CONT 시그널)

STOP 시그널 이외의 시그널을 통해서 프로그램이 종료되면, 2번 index를 의미하는 종료 코드는 0으로 채워지며 시그널에 해당하는 값이 3번 index에 채워지게 된다.

시그널에 의한 종료 (나머지 시그널)

wait의 인자로 사용되는 status에 어떤 값들이 기록되고, 이를 어떻게 취득하는지 알아보았다. 이들을 이용하여 코드를 작성할 때에는 하나의 경우에 대해서만 처리해두는 것보다, WIFEXITED, WIFSIGNALED, WIFSTOPPED, WIFCONTINUED를 모두 분기 처리하고 그에 따라 사용된 값을 각각 취득하여 프로그램이 상황에 맞게 Context를 이어갈 수 있도록 하는 것이 바람작한 방향이라고 볼 수 있다. 아래에 간단한 코드를 두었는데 이와 같은 형식으로 상황에 따라 분기처리를 해주면 된다.

분기 처리

wait 함수의 반환 값과 사용되는 인자에 대해서 알아보았으므로, 아래 예시를 통해 함수 설명 초기에 언급한 부분에 대해서 알아보도록 하자.

4. 예시

#include <stdio.h>
#include <unistd.h>

int	main(void)
{
	pid_t	pid;

	pid = fork();
	if (pid == -1)
		return (1);
	else if (!pid)
		printf("Child: I will be exited\n");
	else
	{
		printf("Parent: I have a Child which pid is %d\n", pid);
		while (1)
			;
	}
	return (0);
}
C
복사

wait 함수를 호출하는 주된 목적은 자식 프로세스의 종료를 기다리는 것 말고도, 부모 프로세스에서 생성된 자식 프로세스를 수거하는 데 있다. 주어진 코드를 실행해보면 부모 프로세스가 무한 루프에 걸려 있기 때문에 자식 프로세스가 출력 구문을 수행한 뒤에 부모 프로세스보다 먼저 종료되는 것을 볼 수 있다. 자식 프로세스가 정상적으로 부모 프로세스보다 먼저 종료되었기 때문에 아무 문제가 없을 것 같지만, 주어진 결과를 살펴보면 자식 프로세스가 여전히 살아서 좀비 프로세스로 유지되고 있는 것을 볼 수 있다. 좀비 프로세스는 이름처럼 부모 프로세스가 종료되기 전까지는 프로세스 테이블에 남아 있는 상태로 유지된다. 따라서 부모 프로세스는 꼭 wait 함수를 호출하면서 자식 프로세스를 수거하여 프로세스 테이블에서 삭제할 의무가 있으므로 이에 따라 주어진 코드를 아래와 같이 wait 함수를 호출하도록 수정해야 한다.

자식 프로세스가 종료되는 즉시 운영체제에서는 자식 프로세스의 모든 자원을 문제 없이 회수하지만, 이 시점에 프로세스 테이블에서 자식 프로세스를 삭제까지 해버리면 부모 프로세스는 자식 프로세스에 대한 상태에 대해 알 수 없는 상황이 되어버린다. 좀비 프로세스를 둔 이유는 이 때문이다.

#include <stdio.h>
#include <sys/wait.h>
#include <unistd.h>

int	main(void)
{
	pid_t	pid;
	pid_t	ret;

	pid = fork();
	if (pid == -1)
		return (1);
	else if (!pid)
		printf("Child: I will be exited\n");
	else
	{
		printf("Parent: I have a Child which pid is %d\n", pid);
		ret = wait(NULL);
		printf("Parent: %d Child has been retrieved\n", ret);
		while (1)
			;
	}
	return (0);
}
C
복사

5) waitpid

1. 의존성

#include <sys/wait.h>
C
복사

2. 함수 원형

pid_t waitpid(pid_t pid, int *status, int options);
C
복사

3. 함수 설명

반환 값 및 status라는 인자는 wait 함수와 동일하기 때문에 이전 항목에서 wait 함수부터 읽어보고 오는 것을 권한다. waitpid 함수에서는 wait 함수와 달리 pid_t 타입으로 된 pid와 int 타입의 option을 추가적으로 인자로 사용하는 것을 볼 수 있다. waitpid의 기능 자체는 wait 함수와 동일하게, 정상적으로 자식 프로세스의 상태를 획득하고 자원을 수거하고 반환하는데 있다. 그렇다면 어떤 기능이 다른지 추가적으로 받은 인자들을 통해 알아보고, waitpid 함수가 만들어진 의의를 알아보자.

wait 함수에서 보았던 이전 예시들을 보면 부모 프로세스에서 생성된 자식 프로세스는 단 1개였다. 만약 부모 프로세스에서 fork를 통해 생성한 자식 프로세스가 1개가 아니라 여러 개라면, wait 함수를 이용했을 때 부모 프로세스의 Context는 임의의 자식 프로세스의 종료를 기다렸다가 수거하게 된다. 즉, 특정 pid를 가진 자식 프로세스에 대한 wait이 불가능하다는 것이다. 따라서 특정 프로세스에 대해서 수행할 수 있도록 waitpid 함수에는 pid라는 인자를 받게 되어 있다. 이 때 waitpid의 pid로 -1이라는 값을 주게 되면, wait과 동일하게 동작하여 임의의 프로세스를 수거하게 된다.

또한 wait 함수의 예시에서 불가피하게 waitpid를 사용했던 것을 볼 수 있었는데, waitpid 함수에는 특정 option을 통해 wait 함수에서 수행하지 못하는 기능들을 수행하도록 만들 수 있다. 이전 예시를 떠올려보면 WUNTRACED, WCONTINUED, WNOHANG들이 있었는데, 이들이 곧 waitpid의 option으로 사용할 수 있는 값들이다. 해당 값들은 비트 단위로 값이 매겨져 있기 때문에, OR 비트 연산을 통해 한번에 option으로 사용할 수도 있다. (여기서 제시된 3개의 option외에도 WEXITED, WSTOPPED, WNOWAIT이 있으므로 이에 대해선 직접 찾아보도록 하자.)

WUNTRACED → STOP 시그널을 통해 실행을 멈춘 자식 프로세스의 status에 대해서 반환

WCONTINUED → CONT 시그널을 통해 실행을 재개한 자식 프로세스의 status에 대해서 반환

WNOHANG → 자식 프로세스의 종료를 기다리지 않고 즉시 자식 프로세스의 status에 대해서 반환

WNOHANG을 사용하면 자식 프로세스의 종료를 기다리지 않기 때문에 WNOHANG을 사용한 waitpid 함수의 호출 시점에 자식 프로세스가 종료되었을 수도 있고 그렇지 않을 수도 있다. 두 경우에는 waitpid의 반환 값이 서로 다르다. WNOHANG을 사용하기 이전에 자식 프로세스가 종료된 경우에는 status가 올바른 값이므로, waitpid의 반환 값은 자식 프로세스의 pid가 된다. 반대로 옵션이 사용되었을 때 자식 프로세스가 종료되지 않은 상태라면 status가 올바르지 않은 값이 되므로, waitpid의 반환 값은 0이 된다.

WUNTRACED 및 WCONTINUED는 wait 함수의 예시에서 보았던 것처럼 STOP 시그널, CONT 시그널을 받은 자식 프로세스에 대해서도 status를 얻어올 수 있도록 만들어준다. wait 함수는 이와 같은 기능을 수행할 수 없으므로 해당 상황에서는 waitpid 함수가 유용하게 이용될 수 있다.

중복된 예시는 작성하지 않을 예정이므로 두 option에 대한 예시는 wait 함수의 예시를 참고하자.

WNOHANG이라는 option은 wait 함수의 예시에서 언급한대로 동기 및 비동기, Block 및 Non-Block이라는 개념이 이용되기 때문에 이에 대한 이해가 선수적으로 요구된다. WNOHANG을 사용하지 않았을 때의 waitpid의 동작은 wait 함수와 크게 다르지 않다. 부모 프로세스에서 wait 함수를 호출하기 전까지는 부모 프로세스와 자식 프로세스 둘 다 각자의 Context를 따라 비동기적으로 실행되고, 부모 프로세스에서 wait 함수를 호출했을 때 곧 부모 프로세스는 Block 상태가 되어 자식 프로세스의 종료 전까지 더 이상의 Context를 이어가지 않는다. 즉, wait 함수와 WNOHANG이라는 option이 없는 waitpid 함수는 자식 프로세스의 종료를 기다리기 위해 Block 상태를 야기하도록 동작한다는 것이 곧 요점이다.

해당 함수들의 Block이라는 기본적인 특성을 잘만 이용하면 자식 프로세스와 부모 프로세스의 동작이 일련의 동기적 흐름으로 실행되도록 만들 수 있다. 따라서 Block이라는 특성은 순서를 지켜서 수행되어야 하는 코드를 만들어야 하는 경우에는 꽤나 큰 장점이 된다. 하지만 과도하게 Block 상태를 만들면 프로그램의 성능 저하로 이어질 수 있기 때문에 주의해야 한다.

프로그램을 작성하다보면 위에서 언급한 것처럼 동기적인 흐름으로만 동작하도록 만들지 않고, Non-Block으로 두어 각 프로세스의 흐름대로 실행하다가 필요할 때만 자식 프로세스를 수거하여 멀티 프로세싱의 장점을 취하도록 만들고 싶은 경우도 있을 것이다. 이 때는 반드시 waitpid의 WNOHANG을 이용해야 한다.

Non-Block을 이용하는 예시를 아래에서 다뤄볼 것인데, 다음과 같은 내용이다. 부모 프로세스는 자식 프로세스의 상태 변화를 SIGCHLD라는 시그널을 Kernel로부터 받게 되면, 별도의 핸들러를 호출하여 자식 프로세스의 status를 취득한 뒤 상황에 맞는 적절한 행동을 수행하도록 한다. 이를 통해 원하는 타이밍에 적절히 waitpid를 호출할 수 있을 뿐 아니라, 자식 프로세스의 종료를 기다리지 않고도 자식 프로세스의 상태 변화에 대해서 status를 즉시 얻음으로써 Non-Block 상태로 흐름을 이어갈 수 있게 된다. 만일 이와 같은 상황에서 WNOHANG을 사용하지 않으면 자식 프로세스가 종료되어야만 status를 알 수 있기 때문에, 자식 프로세스 상태 변화를 감지하고 이에 따라 처리해야할 행동을 바로 바로 처리할 수 없게 된다.

wait 함수를 호출하기 이전에는 자식 프로세스와 부모 프로세스가 각자 자신의 Context를 이어간다는 점을 이용하여 wait 함수를 최대한 미뤄서 부모 프로세스 종료 직전 등에서 호출하도록 만들면 WNOHANG을 사용한 것과 동일하게 Non-Block 상태로 처리되도록 만들 수는 있으나, 이 동작은 여전히 Non-Block을 필요로 하는 상황에 대해서 유연한 흐름을 만들어낼 수 없다.

4. 예시

#include <stdio.h>
#include <sys/wait.h>
#include <unistd.h>

int		main(void)
{
	pid_t	pid;
	pid_t	ret;
	int		status;

	pid = fork();
	if (pid == -1)
		return (1);
	else if (!pid)
	{
		usleep(50000);
		printf("Child1: I am the 1st Child\n");
		return (2);
	}
	else
	{
		pid = fork();
		if (pid == -1)
			return (1);
		else if (!pid)
		{
			usleep(49000);
			printf("Child2: I am the 2nd Child\n");
			return (3);
		}
		else
		{
			printf("Parent: I have 2 Children\n");
			ret = wait(&status);
			printf("Parent: Successfully got status from %d Child\n", ret);
			printf("Parent: Exit Code is %d, Signal is %d\n", WEXITSTATUS(status), WTERMSIG(status));
			ret = wait(&status);
			printf("Parent: Successfully got status from %d Child\n", ret);
			printf("Parent: Exit Code is %d, Signal is %d\n", WEXITSTATUS(status), WTERMSIG(status));
		}
	}
	return (0);
}
C
복사

wait 함수는 2개 이상의 fork된 프로세스에 대해서 순서를 보장하지 않는다는 것을 보이기 위해 usleep 함수를 적절히 이용해보았다. 반복적으로 여러 차례 실행해보면, 어떨 때는 첫 번째 자식 프로세스를 먼저 수거하기도 하고, 어떨 때는 두 번째 자식 프로세스를 먼저 수거하기도 한다. wait 함수는 fork의 순서와 관계 없이 먼저 마친 자식 프로세스를 수거하기 때문에 여러 자식 프로세스들을 두고서 순서에 민감한 작업을 수행해야 하는 상황이라면, 이러한 작업은 프로그램이 실행되고 있는 머신의 성능에 따라서도 차이를 보일 수 있기 때문에 위처럼 wait 함수를 이용하는 것은 좋은 방법이 아니다. wait 함수의 한계를 극복하기 위해선 아래 코드와 같이 waitpid 함수에 직접적으로 pid를 명시함으로써 순서를 보장하도록 만들 수 있다.

사용 중인 머신에 따라서 위 코드를 이용했을 때 고정된 결과가 나올 수 있다. usleep 구문 이후의 코드를 처리하는 속도가 머신마다 다르기 때문이므로, 이런 경우에는 usleep의 값을 적절히 수정하면 된다.

#include <stdio.h>
#include <sys/wait.h>
#include <unistd.h>

int		main(void)
{
	pid_t	pid1;
	pid_t	pid2;
	pid_t	ret;
	int		status;

	pid1 = fork();
	if (pid1 == -1)
		return (1);
	else if (!pid1)
	{
		usleep(50000);
		printf("Child1: I am the 1st Child\n");
		return (2);
	}
	else
	{
		pid2 = fork();
		if (pid2 == -1)
			return (1);
		else if (!pid2)
		{
			usleep(49000);
			printf("Child2: I am the 2nd Child\n");
			return (3);
		}
		else
		{
			printf("Parent: I have 2 Children\n");
			ret = waitpid(pid1, &status, 0);
			printf("Parent: Successfully got status from %d Child\n", ret);
			printf("Parent: Exit Code is %d, Signal is %d\n", WEXITSTATUS(status), WTERMSIG(status));
			ret = waitpid(pid2, &status, 0);
			printf("Parent: Successfully got status from %d Child\n", ret);
			printf("Parent: Exit Code is %d, Signal is %d\n", WEXITSTATUS(status), WTERMSIG(status));
		}
	}
	return (0);
}
C
복사

#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/wait.h>
#include <unistd.h>

void handler(int sig)
{
	pid_t	ret;
	int		status;

	if (sig != SIGCHLD)
		exit(1);
	ret = waitpid(-1, &status, WNOHANG);
	printf("Parent: Successfully got status from %d Child\n", ret);
	printf("Parent: Exit Code is %d, Signal is %d\n", WEXITSTATUS(status), WTERMSIG(status));
	exit(0);
}

int		main(void)
{
	pid_t	pid;

	pid = fork();
	if (pid == -1)
		return (1);
	else if (!pid)
	{
		printf("Child: I am going to take a sleep for 5 seconds\n");
		usleep(5000000);
		return (0);
	}
	else
	{
		printf("Parent: I have a Child which pid is %d\n", pid);
		signal(SIGCHLD, handler);
		while(1)
			;
	}
	return (0);
}
C
복사

SIGCHLD라는 시그널은 자식 프로세스의 상태에 변화가 있을 때 Kenel로부터 부모 프로세스에게 전달된다. 일반적으로 Kernel로부터 SIGCHLD를 받은 부모 프로세스의 기본 처리 동작은 SIG_IGN이다. 이에 대해서 기본 처리 동작을 SIG_IGN이 아니라 사용자가 정의한 핸들러로 동작하도록 signal 함수를 이용하였다. 핸들러 내부에는 waitpid를 호출하여 자식 프로세스의 status를 얻을 수 있도록 했고, WNOHANG을 이용하여 Block 상태를 방지함으로써 즉각적인 반환을 유도하도록 했다. 위와 같이 처리를 하게 되면, 자식 프로세스의 상태 변화가 발생했을 때 특정 행동을 수행할 수 있도록 만들 수 있다. 만일 WNOHANG을 사용하지 않으면 자식 프로세스가 종료하기 전까지 Block 상태에 놓이게 될 뿐만 아니라, 취득한 status 역시 자식 프로세스의 상태 변화를 담고 있지 않고 종료 상태에 대해서만 담고 있는 상황이 벌어진다. 따라서 자식 프로세스의 상태 변화에 따른 특정 행동을 수행하도록 만드는데 어려움이 생긴다. 물론 위의 예시처럼 Non-Block으로 흐름을 제어하더라도 자식 프로세스가 고아 프로세스로 남지 않도록 주의해야 한다.

시그널을 받았을 때 기본 처리 동작은 SIG_IGN, SIG_DFL, 핸들러로 나뉘며, SIG_DFL은 기본 정의된 행동을 하라는 것으로 종료, 무시, 덤프, 중단, 재개 등이 있다. 시그널에 대한 기본 처리 동작은 signal, sigset, sigaction을 통해 재정의 할 수 있으며, sigaction을 이용했을 때는 하나의 시그널을 처리하는 동안 다른 시그널이 오지 않도록 특정 시그널들을 막을 수도 있다. 이를 통해 조금 더 정교한 프로그램을 만들 수 있다

6) dup

1. 의존성

#include <unistd.h>
C
복사

2. 함수 원형

int dup(int fd);
C
복사

3. 함수 설명

dup 계열의 함수는 주로 파일 디스크립터를 활용하는 함수이다. 따라서 파일 디스크립터에 대한 이해가 먼저 필요하다. 이에 대해선 get_next_line에서 리뷰한 바가 있기 때문에 여기서 중복으로 다루진 않을 것이다. dup 혹은 dup2에 대한 설명을 읽기 전에 반드시 아래 링크의 파일 디스크립터를 확인하는 것을 권한다.

get_next_line

Subjects

https://bigpel66.oopy.io/library/42/inner-circle/3

dup 함수는 fd라는 파일 디스크립터를 인자로 받는다. dup 함수의 목적이 파일 디스크립터의 복제이므로 반환 값은 복제된 파일 디스크립터의 값이된다. 만일 파일 디스크립터를 복제하는 과정에서 문제가 발생하면, dup 함수는 -1이라는 값을 반환한다.

get_next_line에서 파일 디스크립터에 대한 내용을 읽었다면, 파일을 열면서 파일 디스크립터가 어떻게 할당하는지 이해했을 것이다. dup 함수의 반환 값은 파일을 열 때의 상황과 동일한 기법을 이용하여 얻어진다. 따라서 dup 함수의 경우에도 inode에 대한 정보를 File Table의 entry에 기록하면서 이에 대한 주소를 FD Table에서 참조할 수 있도록, 순차적으로 FD Table을 탐색하는 과정을 거친다. FD Table의 공간을 0번 index부터 확인하여 File Table의 entry 주소가 담겨 있지 않은 index를 반환하므로, 사용할 수 있는 파일 디스크립터 중에서 가장 작은 값을 반환하게 된다. 이 때 File Table과 VFS inode Cache는 어떻게 동작하는지 알아보자.

일반적으로 동일한 파일을 여러 차례 여는 행위는 파일이 열릴 때마다 별도의 File Table의 entry로 유지된다고 했다. (이 때 각 File Table의 entry가 참조하는 inode는 동일하며, 이를 참조하는 File Table의 entry 수에 따라 inode의 i_count 값이 결정된다.) 하지만 dup 함수의 경우 파일 디스크립터를 얻는다는 점은 파일을 여는 행위와 동일하지만, 내부적으로는 별도의 File Table의 entry를 두는 것이 아니라 동일한 File Table의 entry를 참조하도록 되어 있다. 따라서 dup 함수를 수행하게 되면 해당 File Table의 entry에서 f_count 값이 증가하는 방식으로 동작하게 된다.

dup 함수를 수행하게 되면 인자로 넣은 파일 디스크립터와 반환 값으로 받은 파일 디스크립터가 동일한 파일을 참조하고 있지만, close 함수는 각각 호출해줘야 한다는 점에 유의해야 한다. f_count의 값이 0이 되어야 File Table의 entry가 삭제될 수 있고, 이에 따라 i_count 값도 감소하여 최종적으로는 올바르게 VFS inode Cache에서도 삭제될 수 있다. 각 파일 디스크립터에 대해서 close를 호출할 때마다 File Table의 entry가 갖고 있는 f_count 값이 감소하게 된다.

물론 close 함수를 호출하지 않더라도 프로세스가 종료되면 모든 파일 디스크립터는 자동으로 닫히게 된다. 따라서 프로세스의 종료 시에는 자동으로 f_count가 감소한다고 볼 수 있다. 이에 따라 f_count가 0이 된다면 성공적으로 File Table의 entry는 해제될 것이다. 프로세스의 종료 시에 파일 디스크립터가 자동으로 닫히는 행위에 대해서는 exit 함수의 동작으로 정의되어 있으며, 이는 POSIX에 따라 표준으로 정의된 사항이다. 하지만 사용하지 않는 파일 디스크립터에 대한 적절한 close 함수의 호출이 프로그램을 작성할 때 더 좋은 습관을 만들고, 예기치 못한 동작에 대해서 방지할 수 있다.

4. 예시

#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

int	main(void)
{
	int		fd;
	int		tmp;
	int		ret;
	char	buffer[4096];

	tmp = open("test.txt", O_RDONLY);
	fd = dup(tmp);
	close(tmp);
	if (fd == -1)
		return (1);
	ret = read(fd, buffer, 4096);
	close(fd);
	if (ret == -1)
		return (1);
	buffer[ret] = '\0';
	write(STDOUT_FILENO, buffer, strlen(buffer));
	return (0);
}
C
복사

7) dup2

1. 의존성

#include <unistd.h>
C
복사

2. 함수 원형

int dup2(int fd, int fd2);
C
복사

3. 함수 설명

dup2의 역할은 dup 함수와 동작 방식이 동일하다. 따라서 파일 디스크립터에 대한 내용, 파일 디스크립터의 처리 흐름, 파일 디스크립터의 복제 과정에 대해서는 dup 함수를 확인하는 것을 권한다.

dup2 함수는 dup 함수와 비교했을 때, 사용 방법에 차이가 있다. 인자로 넣은 fd라는 파일 디스크립터를 복제하고 현재 사용하고 있지 않은 파일 디스크립터 중 가장 작은 값을 반환하는 것이 dup이었다면, dup2의 경우에는 반환 값이 사용자가 원하는 fd2라는 값이 나올 수 있도록 fd라는 인자를 사용하여 복제를 수행한다. 즉, 복제 과정에서 문제가 생기지 않는다면 dup2의 반환 값은 fd2가 된다.

복제 과정에서 문제가 생긴다면 dup 함수와 마찬가지로, dup2 함수도 -1을 반환한다.

만일 복제 과정에서 fd2가 기존에 이미 열려서 사용되고 있는 값이라면 어떻게 될까? 이는 복제 과정에서의 오류로 처리하지 않고 기존의 파일 디스크립터를 close하여 File Table의 entry와 inode를 처리하여, File Table의 entry를 참조하고 있지 않은 상태의 파일 디스크립터로 만들어서 복제를 수행할 수 있도록 만든다.

dup 함수가 이미 존재하는데도 불구하고 dup2 함수를 만들어둔 이유는 유연한 파일 디스크립터의 이용을 위해서이다. dup2 함수는 주로 pipe 함수와 함께 많이 쓰이는데, pipe 함수에서 사용되는 파일 디스크립터를 표준 입력과 표준 출력을 참조하는 index가 복제할 수 있도록 주로 사용된다. 이를 통해 pipe로 연결된 프로세스 간에 명령어를 처리할 때 표준 입력과 표준 출력을 이용하기 위해 0번 index와 1번 index를 이용한다면, 실제로는 표준 입력과 표준 출력을 이용하는 것이 아니라 복제한 파일 디스크립터의 파일을 이용하게 된다. pipe에 대해선 차후의 항목에서 다루므로 이와 비슷한 예시를 아래에서 다뤄볼 것이다.

만일 dup2가 존재하지 않아서 dup으로만 이를 처리해야 한다면 굉장히 까다로운 상황이 발생할 수 있다. 사용자가 원하는 값 이전까지는 파일 디스크립터를 열어둬야 하고, 사용자가 원하는 값이 이미 점유되었다면 close를 호출해줘야 한다. 마침내 dup을 호출하게 되어 원하는 값을 할당 받았다면, 이를 위해 이전에 열어둔 사용되지 않는 파일 디스크립터를 close 하는 과정을 거쳐야 한다. 물론 이와 같은 복잡한 과정이 싫어서 dup2와 동일한 동작을 만들어 내지 않는다고 한다면, 단순히 dup 함수만을 이용하고 반환 받은 파일 디스크립터를 문제 없이 사용할 수 있도록 dup 함수의 호출자에서 이를 적절히 처리해줘야 하는 상황이 발생한다.

예시에서 사용된 코드의 상황은 위의 그림과 같은 상황이다. 이 때 dup2를 호출하게 되면 기존 0번 index의 파일 디스크립터가 닫히고, 3번 index에 대한 File Table의 entry를 참조하도록 복제가 이뤄진다. 복제 후에 기존 0번 index가 참조하고 있는 File Table의 entry가 현재 프로세스에 의해서 전혀 참조되고 있지 않음에도 File Table에서 해제되지 않은 이유는 다른 프로세스들도 표준 입력을 위해서 해당 entry를 참조하고 있기 때문이다. (즉, 표준 입력을 위한 entry의 f_count는 비록 현재 프로세스의 0번 index가 참조를 끊더라도 0이 되는 경우는 없다고 보면 된다.)

4. 예시

#include <stdio.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>

int	main(void)
{
	int fd;
	int tmp;
	int ret;
	char buffer[4096];

	tmp = open("test.txt", O_RDONLY);
	fd = dup2(tmp, STDIN_FILENO);
	close(tmp);
	if (fd == -1)
		return (1);
	ret = read(STDIN_FILENO, buffer, 4096);
	if (ret == -1)
		return (1);
	buffer[ret] = '\0';
	write(STDOUT_FILENO, buffer, strlen(buffer));
	return (0);
}
C
복사

8) pipe

1. 의존성

#include <unistd.h>
C
복사

2. 함수 원형

int pipe(int fd[2]);
C
복사

3. 함수 설명

흔히 프로세스 간의 통신을 IPC (Inter Process Communication)이라 부른다. IPC를 수행하기 위해선 데이터를 주고 받기 위한 특정 공간이 요구된다. 하지만 프로세스들은 메모리 상에 각각 독립된 공간을 할당받아 위치하고, 이들은 서로 공유될 수 없기 때문에 특별한 방식 없이는 IPC 수행에 어려움이 있다.

IPC를 수행하기 위한 방식으로는 파일, 메세지 큐, 공유 메모리 소켓 등이 있으며, fork, wait, waitpid에서 소개된 시그널도 IPC 방식 중 하나이다. 이와 같은 IPC 방식은 크게 공유 메모리 기법과 메세지 교환 기법으로 나뉘는데, 메세지 교환 기법 중에서도 fork를 이용했을 때 자식 프로세스와 부모 프로세스가 서로 통신하는데 이용되는 IPC 방식이 파이프이다.

제시된 IPC 방식들이 모두 양방향 통신을 지원하는 것은 아니다. 따라서 사용하려는 IPC 방식이 양방향 통신을 지원하는지 먼저 확인하고, 그렇지 않다면 양방향 통신을 위해 별도의 작업을 거쳐야 한다.

이전 항목의 예시에서 작성된 코드를 보면 자식 프로세스와 부모 프로세스 간에 시그널을 주고 받는 것을 볼 수 있는데, 이는 보내진 시그널에 따라 각 프로세스가 수행할 동작을 정의하는 등으로 사용되기 때문에 상호 간에 데이터를 주고 받는데는 어려움이 있다. 따라서 자식 프로세스와 부모 프로세스가 서로 데이터를 주고 받기 위해선 시그널보다는 파이프를 이용해야 한다. 이 때, 자식 프로세스와 부모 프로세스 사이에 파이프를 두기 위해 이용되는 함수가 pipe이다.

파이프라는 IPC 방식은 파일 디스크립터를 이용하여 자식 프로세스와 부모 프로세스 간에 데이터를 주고 받을 수 있도록 해준다. 파이프는 단방향 통신이기 때문에, 자식 프로세스와 부모 프로세스 간 파이프를 개설하게 되면 한 쪽에서는 Read 작업만 가능하고 다른 쪽에서는 Write 작업만 가능하다. 그리고 비록 파이프가 파일 디스크립터를 이용하긴 하나, 이는 파일에 대한 파일 디스크립터가 아닌 운영체제로부터 할당 받은 특정 버퍼에 대한 파일 디스크립터이다. 따라서 파이프에 Write할 수 있는 데이터는 할당 받은 버퍼의 크기만큼이라는 제한이 있다.

따라서 이전에 언급했던 것처럼 파이프를 이용하여 두 프로세스가 양방향 통신을 위해선, 각 프로세스가 모두 읽고 쓰는 작업이 가능해야 하므로 2개의 파이프를 두어야 한다.

파일 디스크립터를 이용하여 프로세스 간에 통신이 가능한 이유는 파일 디스크립터가 참조하는 파일 자체는 디스크 상의 별도의 공간으로 유지되면서 프로세스의 메모리 공간을 침해하지 않고, 이들은 어떤 프로세스에서도 접근이 가능하기 때문이다. 즉, 이론적으로 각 프로세스에서 사용하고 있는 Read 용도의 파일 디스크립터와 Write 용도의 파일 디스크립터가 동일한 파일을 참조하도록 되어 있다면, 해당 파일 디스크립터를 읽고 쓰면서 통신이 가능하게 되는 것이다.

이와 같은 작업이 특히 자식 프로세스와 부모 프로세스 간에 많이 이용되는 이유는 자식 프로세스의 생성이 fork를 통해서 이뤄지고, fork 함수는 부모 프로세스의 모든 메모리 공간과 PC까지 그대로 복제하여 자식 프로세스에게 할당하는 특성을 갖고 있기 때문이다. 따라서 fork 수행 이전에 pipe 함수를 호출하여 Read, Write 용도의 두 파일 디스크립터를 연결해두었다면, fork 함수 수행 이후에 자식 프로세스에서도 이 상태가 그대로 유지되고 있게 된다. 비록 파일 디스크립터가 프로세스 단위로 관리되기는 하지만 이미 서로 동일한 파일을 참조하도록 설정되어 있기 때문에 자식 프로세스와 부모 프로세스는 원활하게 통신할 수 있다.

함수의 형태를 살펴보면, pipe 함수는 위에서 설명된 것처럼 2개의 파일 디스크립터를 인자로 받아 이용하는 것을 볼 수 있다. pipe의 fd에 파일 디스크립터들이 성공적으로 할당된다면 이 값을 이용할 수 있게 되고 0을 반환한한다. fd에 파일 디스크립터를 할당하는 과정에서 문제가 생긴다면 pipe는 즉시 -1을 반환한다.

이 때 인자로 사용되는 fd는 크기가 2인 int 타입의 배열인데, fd[0]은 Read에 이용되고 fd[1]은 Write에 이용된다. 위의 그림처럼 a라는 프로세스에서 fd[1]을 이용하여 hi를 썼다면, b라는 프로세스에서는 fd[0]을 이용하여 hi를 읽을 수 있다는 것이다.

아래 예시에서 pipe에서 사용할 파일 디스크립터를 할당 받고, 이를 각각 dup2를 이용하여 표준 입력을 위한 index와 표준 출력을 위한 index로 복제함으로써 주고 받은 데이터를 파일에 기록해볼 것이다. 예시에 대한 각 프로세스의 상황은 아래 그림과 같다.

자식 프로세스

부모 프로세스

4. 예시

#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/wait.h>
#include <unistd.h>

#define P_READ			0
#define P_WRITE 		1
#define BUFFER_SIZE	4096

void	childcommand(void)
{
	int				ret;
	char			buffer[BUFFER_SIZE];

	ret = read(STDIN_FILENO, buffer, BUFFER_SIZE);
	buffer[ret] = '\0';
	write(STDOUT_FILENO, buffer, strlen(buffer));
}

void	childproc(int pipe[2])
{
	int				fd;
	int				r_fd;
	int				w_fd;

	printf("Child: I'm going to close fd for Read\n");
	printf("Child: I'm going to connect STDOUT to fd for Write\n");
	printf("Child: I'm going to connect STDIN to fd from a file\n");
	printf("Child: Eventually I'll read from STDIN (file) and write to STDOUT (pipe)\n");
	close(pipe[P_READ]);
	w_fd = dup2(pipe[P_WRITE], STDOUT_FILENO);
	close(pipe[P_WRITE]);
	if (w_fd == -1)
		exit(1);
	fd = open("read.txt", O_RDONLY);
	if (fd == -1)
		exit(1);
	r_fd = dup2(fd, STDIN_FILENO);
	close(fd);
	if (r_fd == -1)
		exit(1);
	childcommand();
}

void	parentcommand(void)
{
	int				ret;
	char			buffer[BUFFER_SIZE];

	ret = read(STDIN_FILENO, buffer, BUFFER_SIZE);
	buffer[ret] = '\0';
	write(STDOUT_FILENO, buffer, strlen(buffer));
}

void	parentproc(int pipe[2], pid_t pid)
{
	int				fd;
	int				r_fd;
	int				w_fd;

	printf("Parent: I'm going to close fd for Write\n");
	printf("Parent: I'm going to connect STDIN to fd for Read\n");
	printf("Parent: I'm going to connect STDOUT to fd from a file\n");
	printf("Parent: Eventually I'll read from STDIN (pipe) and write to STDOUT (file)\n");
	close(pipe[P_WRITE]);
	r_fd = dup2(pipe[P_READ], STDIN_FILENO);
	close(pipe[P_READ]);
	if (r_fd == -1)
		exit(1);
	fd = open("write.txt", O_WRONLY);
	if (fd == -1)
		exit(1);
	w_fd = dup2(fd, STDOUT_FILENO);
	close(fd);
	if (w_fd == -1)
		exit(1);
	if (waitpid(pid, NULL, 0) == -1)
		exit(1);
	parentcommand();
}

int	main(void)
{
	int				 fd[2];
	pid_t			 pid;

	if (pipe(fd) == -1)
		return (1);
	printf("Parent: fd for Read is %d, fd for Write is %d\n", fd[P_READ], fd[P_WRITE]);
	pid = fork();
	if (pid == -1)
	{
		close(fd[P_READ]);
		close(fd[P_WRITE]);
		return (1);
	}
	else if (!pid)
		childproc(fd);
	else
		parentproc(fd, pid);
	return (0);
}
C
복사

9) execve

1. 의존성

#include <unistd.h>
C
복사

2. 함수 원형

int execve(const char *file, char * const *argv, char * const *envp);
C
복사

3. 함수 설명

위 그림을 보면 알 수 있듯이 exec 계열의 함수는 다양하지만, 첫 번째 인자로 실행할 파일의 경로를 받는다는 것에는 차이가 없다. exec 계열의 함수를 이용하면 첫 번째 인자를 이용하여 해당 경로의 파일을 실행하면서 새로운 프로세스를 만들어내고, 현재 프로세스에서 새롭게 만들어진 프로세스로 흐름을 교체한다. 이 때 새로운 프로세스 내에는 새롭게 초기화 된 스택, 힙, 데이터 영역을 갖는다. 이는 fork와 같이 별도의 프로세스가 구동되는 것이 아닌, 새로운 프로세스가 현재 프로세스를 교체하는 행위로 이뤄지기 때문에 자식 프로세스와 부모 프로세스의 관계를 갖는 형태가 아니다. 따라서 exec 계열의 함수로 생성된 프로세스는 동기적인 특성을 갖는다.

예를 들어 현재 프로세스 내에서 exec 계열 함수가 첫 번째 인자로 /bin/ls를 이용했다면 exec 함수에 의해서 /bin/ls가 실행되면서 새로운 프로세스가 생기고, 실행 흐름은 /bin/ls로 넘어가게 된다. 여기서 새로운 프로세스를 생성되는 것이 인자를 실행시키면서 이뤄지는 것이므로, exec 계열의 첫 번째 인자에 대해선 실행 권한이 있는지 확인이 꼭 필요하다. 이는 위에서 배운 access 함수를 통해서 선행 검사가 가능하다.

만일 exec 계열의 함수가 인자로 받은 파일에 대해서 실행하고 이를 처리하는데 아무런 문제가 없다면, 0을 반환한다. 반대로 문제가 생기게 되면, -1을 반환한다. 이를 유념해두고 각 함수들에 대해서 알아보자.

exec 계열의 함수는 그 이름들에서 어떤 규칙을 찾을 수 있는데, 함수 이름 뒤에 l, v, e, p가 붙는 것을 볼 수 있다. l은 list, v는 vector, e는 environment, p는 path를 의미한다.

유심히 살펴보면 대체적으로 execl 계열과 execv 계열로 나뉘는 것을볼 수 있는데, l과 v가 곧 exec 함수로 실행할 파일에 사용되는 값을 list로 일일이 주어줄지 vector로 한 번에 주어줄지를 의미하므로, 두 번째 인자 이후 부터 인자의 형태가 달라지는 것을 볼 수 있다. l 계열 함수들은 가변 인자를 이용하는 것을 볼 수 있고, v 계열 함수에서는 가변 인자를 이용하지 않는 것을 볼 수 있다.

이 때 l 계열이든 v 계열이든 두 번째 인자를 이용할 때 주의할 점이 있는데, 파일을 실행하면서 생기는 새로운 프로세스에는 argc에 대한 정보가 없기 때문에 argv의 가장 마지막 요소에는 NULL이 있어야 한다. 그리고 argv가 인자라고 하더라도 argv의 가장 첫 요소에는 사용할 명령어가 반드시 기재 되어야 한다. execl과 execv를 이용하여 ls -al test.txt를 이용하고자할 때 어떤 식으로 각 함수의 인자를 두어야 하는지 생각해보자.

execl (calling ls -al test.txt)

execv (calling ls -al test.txt)

l 계열 함수를 이용할지 v 계열 함수로 이용할지 정한 뒤에는 실행할 파일을 상대 경로로 줄지, 절대 경로로 줄 지에 따라 p의 유무가 갈린다. p를 이용한 execlp, execvp와 같은 함수들은 $PATH라는 환경 변수를 이용하여 첫 번째 인자를 처리한다. 이와 같은 함수들은 $PATH에 등록된 경로 내에 동일한 파일이 있는 경우에 문제가 된다. 특히 이와 같은 문제는 $PATH 내의 경로를 삽입하여 실행할 프로그램에 대해 강제로 바꾸는 것이 가능하기 때문에 보안 취약 문제로 이어질 수 있다. 따라서 절대 경로를 이용하는 나머지 함수들을 이용하는 것이 좋다.

exec의 e 계열 함수들인 execle, execve와 같은 함수들은 e의 의미에서 알 수 있듯이, 환경 변수를 함수의 가장 마지막 인자로 넘겨서 내부적으로 이를 이용한다. 환경 변수를 사용하지 않을 것이라면 execl 혹은 execv를 써도 좋지만, execle 혹은 execve를 사용하면서 환경 변수에 해당하는 인자에 NULL을 주어도 된다. e 계열 함수들을 이용하면서 주의할 점은 가장 마지막 인자로 환경 변수를 넘길 때, 인자의 가장 마지막 요소는 NULL이어야 한다는 것이다.

execle 함수가 실행할 파일에 넘길 인자들을 가변 인자로 처리 했음에도 가장 마지막 인자를 환경 변수로 인식할 수 있는 이유는 가장 마지막 인자 이전에 NULL로 구분이 되어 있기 때문이다.

execve 함수를 통해 gcc를 실행함으로써, 새로운 실행 파일을 만들어 보는 과정을 알아보자.

4. 예시

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int	main(int argc, char **argv)
{
	int		i;
	char	**args;

	if (argc == 1)
		return (1);
	i = -1;
	args = (char **)malloc(argc * sizeof(char *));
	if (!args)
		return (1);
	args[argc - 1] = NULL;
	while (++i < argc - 1)
		args[i] = argv[i + 1];
	execve("/usr/bin/gcc", args, NULL);
	free(args);
	return (0);
}
C
복사

2. Approach

1) 다중 명령어

명령어 수보다 하나 작은 만큼 파이프가 존재하므로 기존에는 아래 의사 코드와 같이 파이프의 수만큼 동적할당을 받고, 반복문을 돌 때 index를 계산하여 pipe 함수에 넣도록 만들었다.

int i;
int *fd;

fd = (int *)malloc(num_pipe * 2 * sizeof(int));
if (!fd)
	exit (1);
i = -1;
while (++i < num_pipe)
	if (pipe(num_pipe * 2) < 0)
		exit(1);

/*
** cmd0    cmd1    cmd2    cmd3    cmd4 ...
**     pipe0   pipe1   pipe2   pipe3    ...
**     [0,1]   [2,3]   [4,5]   [6,7]    ...
*/
C
복사

우선 위와 같은 방법에 대해선 파이프로 사용할 파일 디스크립터를 얻는데 동적할당을 사용한다는 점이 마음에 들지 않았고, 처리해야할 명령어들이 많은 파이프를 요구한다면 그에 비례하는 메모리를 이용해야 한다는 점도 마음에 들지 않았다.

따라서 파이프를 적게 쓸 수 있는 방법에 대해서 고민을 하다가, 파이프가 단방향 통신으로 이용된다는 점과 fork로 생성된 부모 및 자식 관계의 프로세스는 서로 동일한 메모리 구조를 갖는 점을 이용하여 2개의 파이프만으로 다중 명령어를 처리할 수 있도록 구상해보았다.

이전 방법에서 주어진 파이프가 이용하는 Read와 Write의 파일 디스크립터를 2개로 줄였을 때 동작은 아래의 의사 코드로 나타낸 것처럼 명령어의 index가 짝수일 때는 B 파이프에서 읽고 A 파이프에 쓰며, 홀수일 때는 A 파이프에서 읽고 B 파이프에 쓰는 것을 알 수 있다.

/*
** cmd0 -> Read from file, Write on A pipe
** cmd1 -> Read from A pipe, Write on B pipe
** cmd2 -> Read from B pipe, Write on A pipe
** cmd3 -> Read from A pipe, Write on B pipe
** ...
*/
C
복사

따라서 명령어만큼의 반복문을 돌리고 내부에서 fork를 통해 명령어를 수행할 자식 프로세스를 만든다고 했을 때, 자식 프로세스의 반복문 index가 짝수인지 홀수인지에 따라 어떤 파이프의 Read 혹은 Write를 이용할지 만들어주면 된다. 만일 사용하지 않는 Write에 대한 파일 디스크립터가 자식 프로세스에서 남아 있게 되면 명령어 처리 시 무한히 대기하는 현상을 볼 수 있기 때문에 Write에 대한 파일 디스크립터를 적절히 닫는 과정이 필요하다. 이는 단순히 자식 프로세스에서 해당 파일 디스크립터를 닫으면 될 것 같지만, 실제로는 그렇게 단순하지 않다.

예를 들어, cmd1은 명령어 index가 홀수이므로 반복문 내의 fork 시점 이전에 B 파이프를 생성하게 될 것이다. 그리고 fork 이후의 자식 프로세스에서는 B 파이프에 원하는 내용을 기록하게 될 것인데, 이에 대해 필요한 인자들은 A 파이프에서 읽도록 유도해야 한다. 이전 반복문의 자식 프로세스에서는 A 파이프에 이미 내용을 기록했을 것이므로 A 파이프에서 내용을 읽는데는 문제가 없지만, 부모 프로세스에서는 A 파이프에 내용을 기록하지 않을 것이기 때문에 Write에 대한 파일 디스크립터를 닫아 두어야 한다. 그래야 현 fork 시점에 자식 프로세스는 A 파이프에 대해서 Write는 닫혀 있는 상태로 Read를 수행하고, 열려 있는 Write에 대한 파일 디스크립터가 없으므로 대기 없이 정상 종료된다.

cmd0는 읽을 내용이 파이프에 있는 것이 아니라 파일에 있고, 가장 마지막 cmd는 쓸 내용이 파이프가 아니라 파일에 있으므로 두 경우에 대해서는 별도의 처리가 필요하다.

필요한 시점마다 Write에 대한 파일 디스크립터를 자식 프로세스에서 닫으면 안 되는지 의문이 들 수 있는데, 파이프의 사용하지 않을 Write에 대한 파일 디스크립터를 닫는 과정은 부모 프로세스에서도 필요하기 때문에 중복으로 닫는 구문을 넣다가는 동기화를 조금만 잘못하면 Bad File Descriptor를 볼 수 있게 된다. 따라서 최대한 안전하게, fork 시점 이전에 공통적으로 처리할 수 있는 부분에 대해서 먼저 처리를 해주는 것이 바람직하다.

위 내용에 대한 요지는 짝수의 index와 홀수의 index의 명령어에서 사용할 파이프를 적절히 생성하고, 사용하지 않을 파일 디스크립터에 대해서는 이전 반복문에서 사전에 처리를 해줘야 현 fork 시점에 문제가 없다는 것이다. 아래 의사 코드를 확인해보자.

int pipeA[2];
int pipeB[2];
int i;
pid_t pid;

i = -1;
while (++i < num_pipe + 1)
{
	if (!(i % 2))
		if (pipe(pipeA) < 0)
			exit(1);
	if (i % 2)
		if (pipe(pipeB) < 0)
			exit(1);
	pid = fork();
	if (pid == -1)
		exit(1);
	else if (!pid)
		child_proc();
	else
		parent_proc();
}

/*
** child_proc
** (각 과정에 대한 처리에서 필요 없는 파일 디스크립터를 적절히 닫는 과정이 필요하다.)
**
** 최초: 파일에서 읽는 작업을 수행
**
** 최종: 파일에 쓰는 작업을 수행
**
** 중간: 짝수 index인지, 홀수 index인지에 따라 어느 파이프의 Read, Write를 Redirection할 지 달라진다.
**      홀수 index -> A 파이프에서 읽어야 하므로 A 파이프의 Read를 STDIN으로 dup2를 수행한다.
**                   B 파이프에 써야 하므로, B 파이프의 Write를 STDOUT으로 dup2를 수행한다.
**      짝수 index -> B 파이프에서 읽어야 하므로 B 파이프의 Read를 STDIN으로 dup2를 수행한다.
**                   A 파이프에 써야 하므로, A 파이프의 Write를 STDOUT으로 dup2를 수행한다.
*/

/*
** parent_proc의 명령어 index에 따른 처리
** (현 index의 처리는 fork 시점 이후 임을 명심한다.)
** 
** 최초: 짝수 index이고 읽을 내용은 파일에 있으므로, A 파이프의 Write만 닫는다.
**
** 최종: 짝수 index인지, 홀수 index인지에 따라 어느 파이프의 Write를 닫는지 달라진다.
**      홀수 index -> 기존에는 B 파이프에 Write를 하겠지만, 파일에 Write를 수행할 것이므로 B 파이프의 Write는 필요가 없다.
**      짝수 index -> 기존에는 A 파이프에 Write를 하겠지만, 파일에 Write를 수행할 것이므로 A 파이프의 Write는 필요가 없다.
**
** 중간: 짝수 index인지, 홀수 index인지에 따라 어느 파이프의 Read, Write를 닫는지 달라진다.
**      홀수 index -> 다음 반복문은 짝수 index이므로 B 파이프에서 읽고, A 파이프에 쓸 것이다.
**                   따라서 B 파이프의 Write를 닫고, A 파이프의 Read를 닫는다.
**      짝수 index -> 다음 반복문은 홀수 index이므로 A 파이프에서 읽고, B 파이프에 쓸 것이다.
**                   따라서 A 파이프의 Write를 닫고, B 파이프의 Read를 닫는다.
**
** 명령어 index에 따른 처리가 끝났다면, 자식 프로세스의 현 명령어 수행을 기다리도록 적절히 wait / waitpid를 이용한다.
** 만일 자식 프로세스에서 Exception이 발생했다면, 적절히 status를 분석한다.
** exec 함수는 자식 프로세스 자체를 교체하여 수행된다는 점을 유의해야 한다.
*/
C
복사

위 코드를 보면 마지막 명령어의 Read에 대한 파일 디스크립터가 닫히지 않은 것을 볼 수 있는데, 코드 구동에 있어서 문제가 되는 것은 Write에 대한 파일 디스크립터가 닫히지 않은 경우이다. 하지만 그 외 중간 명령어의 파일 디스크립터들은 Read, Write에 대해 닫는 것을 볼 수 있는데, 이는 동일한 번호의 파일 디스크립터를 유지하기 위함이다. 이미 열려 있는 파일 디스크립터를 갖고 있는 파이프에 다시 pipe를 수행해도 오류는 나지 않으나, 기존에 열려 있던 파일 디스크립터의 번호를 버리고 새로운 파일 디스크립터를 얻어내는 것을 볼 수 있다. 즉, 중간 명령어에 대해선 현재 사용 중인 파이프의 파일 디스크립터들을 적절히 닫아주지 않으면 동일한 번호의 파일 디스크립터를 유지할 수 없게 된다. 이와 같이 파일 디스크립터를 유지하는 것은 문제가 될 가능성이 굉장히 높으며, 혹여나 동작 자체에는 문제 없더라도 할당 받을 파일 디스크립터가 없을 경우가 있을 수도 있다는 점을 유의해야 한다.

2) here_doc에 따른 사용자 입력 처리

here_doc을 명시하면 사용자가 직접 입력한 내용을 표준 입력으로 처리하여 명령어가 이를 받을 수 있도록 만들어야 한다. 단, ctrl + D를 이용하지 않고 limiter에 해당하는 문자열이 나오면 표준 입력을 마치도록 해야한다. 따라서 아무런 작업 없이 exec 계열 함수가 표준 입력을 이용하게 둔 경우에는 limiter에 대한 구분이 불가능하므로 다른 방법이 요구된다.

우선 get_next_line을 이용하여 표준 입력으로 limiter 전까지 받도록 만들어 내고 이를 exec 계열 함수가 이용할 수 있도록 만들어야 한다. 이 때 이용할 수 있는 방법은 2가지가 있다. 첫 째는 파이프를 이용한 방법이고, 둘 째는 임시 파일을 이용한 방법이다.

파이프를 이용하게 되면 별도의 파일을 유지하지 않아도 되고, 이에 대해서 프로그램 종료 시점에 파일을 삭제하는 행위를 거치지 않아도 된다. 하지만 파이프 자체가 유지할 수 있는 데이터 자체는 설정에 따라 정해진 버퍼 사이즈 만큼이기 때문에, 파이프를 이용하기 전에 표준 입력을 사전에 돌리는 작업이 요구된다. 그리고 표준 입력을 사전에 돌리는 작업 자체는 동일 프로세스에서 진행 시에 get_next_line으로 limiter 전까지 받아내는 작업이 불가능하므로, fork를 통해 별도의 자식 프로세스에서 진행해야 한다.

임시 파일을 이용하게 되면 비록 파일에 대한 관리가 요구되긴 하나, 파이프와 같이 조금은 복잡한 과정을 거치지 않아도 되며 버퍼 사이즈 제한으로부터 자유로우므로 데이터 크기에 대해서 신경 쓸 필요가 없어진다. 따라서 사전에 표준 입력을 돌릴 필요가 없어지므로, fork 작업이 요구되지 않는다.

pipex에서 unlink 함수를 허용하지만 아직까지 사용이 되지 않았기 때문에 unlink 함수를 여기서 사용하면 되겠다는 생각이 들었고, 파이프를 이용하여 표준 입력을 돌려 놓는 작업이 명령어 실행 전에 이뤄져 비록 명령어 실행 전이라 읽히지는 않으나 접근이 가능하다는 점 때문에 limiter의 의미와는 조금 거리가 있다는 생각이 들었다. 고로 두 방법 중 어느 방법을 사용하여도 무방하다고 생각이 되나, 여러 번복을 통해 임시 파일을 만드는 방식으로 진행하기로 했다.

여기까지 생각할 수 있도록 도와주신 hyechoi님, hyeonski님, hyeonsok님 감사합니다.

1. 파이프를 이용한 here_doc 처리

파이프 생성 후 fork 시도

부모 프로세스 : 파이프의 Write 닫기

부모 프로세스 : dup2를 통해 파이프의 Read를 표준 입력으로 돌린 후, 파이프의 Read 닫기

부모 프로세스 : 대기

자식 프로세스 :  파이프의 Read 닫기

자식 프로세스 : get_next_line을 통해 표준 입력으로 읽은 문자열을 파이프의 Write에 기록

자식 프로세스 : limter를 만나면 파이프의 Write 닫기

자식 프로세스 : 종료

2. 임시 파일을 이용한 here_doc 처리

O_WRONLY, O_CREAT, O_TRUNC 모드 및 0644 권한으로 임시 파일 생성

limiter가 나오기 전까지 임시 파일에 기록

limiter를 만나면 기록을 중지하고 임시 파일을 닫기

O_RDONLY 모드로 임시 파일 다시 열기

dup2를 통해 표준 입력을 임시 파일로 돌리기

임시 파일 닫기

3) 기타

위에서 처리해야 하는 내용들 외에도 아래와 같이 한 번 쯤은 생각해봐야 하는 것들이 있다.

다중 따옴표 처리

명령어 경로 설정

명령어 처리 단위

오류 문구 처리

1번에 대해선 먼저 나온 따옴표 쌍에 맞춰서 파싱을 진행해야 하며, 따옴표 내에 있지 않은 내용들은 공백 문자를 기준으로 파싱을 진행해야 한다. 이 때 먼저 발견한 따옴표 쌍 자체는 exec 함수의 인자로 넘길 때 포함 되어서는 안 된다. 예를 들어 awk '\"{count++} END {print count}\"'의 경우, exec 계열 함수의 인자로는 awk, \"{count++} END {print count}\"와 같이 따옴표를 제외하고 들어가게 된다.

수행할 명령어는 항상 /bin에만 있는 것도 아니고, /usr/bin에만 있는 것도 아니다. 정해진 명령어를 이용할 수 있는 상황도 아니기 때문에 명령어에 대한 경로를 미리 설정해두는 것에도 무리가 있다. 따라서 최대한 쉘의 동작과 유사하게 작업을 해야하므로, 상황에 따라 적절한 경로의 명령어를 이용할 수 있도록 $PATH를 이용해야 한다. 이에 따라 main 함수에서 세 번째 인자로 char **envp를 받도록 만든다. envp를 통해 pipex 구동 시점의 모든 환경 변수를 얻어왔다면, $PATH라는 환경 변수를 : 단위로 파싱을 하여 접근하려는 파일 이름을 붙이고 파일의 존재 유무를 확인하면 된다. 만일 파일이 존재하지 않는다면 파싱된 그 다음 경로를 이용하여 파일의 존재 유무를 확인하면 되고, 끝까지 존재하지 않는다면 파일 이름 그대로를 이용한다. 이와 같이 설정된 명령어 경로를 이용하여 exec 계열 함수로 실행을 했을 때 오류가 발생한다면, 쉘에서의 다양한 오류 구문과 유사하게 적절한 작업이 요구되는 것을 잊어선 안 된다.

결국에 $PATH 환경 변수를 이용하면서 execvp를 이용하지 않는 이유는, execvp는 pipex 구동 도중 변경된 $PATH에 대해서도 영향을 받을 수 있기 때문이다. 이는 $PATH Injection Attack으로 이어질 수 있어 상대적으로 더 보안에 취약하다.

3번에 대해서 간과하기 쉬운 것 같다는 생각이 들었다. 처음에 pipex를 구현할 때 파이프로 넘어가기 전에 오류가 나면 전체 프로그램을 종료하는 방식을 고집했는데, 실제 쉘에서는 파이프로 구분된 명령어들 사이에 오류가 생기면 즉시 종료되지 않고 파이프 단위로 나뉜 명령어들을 모두 처리하는 것을 볼 수 있었다. 예를 들어서 grep hello | wc -l 과 같은 2개의 명령어가 있다고 해보면, grep에서 오류가 난다고 해서 종료되는 것이 아니라 grep에서 오류가 나더라도 wc는 들어오는 인자가 없는 것으로 생각하고 정상적으로 동작한다는 것이다. 즉, 파이프를 이용하게 되면 명령어 처리 단위는 전체가 아닌 파이프 단위임을 명심해야 한다.

쉘에 대해선 bash 혹은 zsh를 많이 이용한다. 대체적으로 두 쉘에서 내는 오류 문구들이 비슷하거나 동일한 경우가 많아서, 오류 문구에 대해서도 정확히 맞춰야 하는가에 대해 고민이 들 수도 있겠다는 생각이 들었다. 하지만 쉘은 bash, zsh만 있는 것은 아니다. 두 쉘 외에도 sh, csh, ksh, tcsh 등 다양한 쉘이 존재한다. 이 쉘들 내에서도 모든 오류 문구가 동일하지는 않다. 잘 생각해보면 이들도 서로 다른 개발자들에 의해 만들어진 서로 다른 프로그램에 불과하다. 오류에 대한 처리가 되었다는 점은 동일하지만 모든 문구가 일치하지는 않는다. 따라서 pipex를 구현할 때도 맥락 상 어떤 오류가 발생했는지 파악만 가능하다면 오류 문구가 달라도 크게 문제가 없다는 생각이 든다. 특히 pipex에서는 모든 문구를 맞추고자 한다면 인자가 디렉토리인지 아닌지에 대한 구분이 필요할 때가 있는데, pipex에서는 <sys/stat.h>의 stat 구조체와 관련 함수들이 허용되지 않았기 때문에 정확하게 문구를 맞추는데는 무리가 있다. 처리가 불가능한 문구 외에는 최대한 오류에 대한 의미 전달이 가능하도록 만들어야 한다.