슭의 개발 블로그

지난 글 에서 설명했듯이 OS X, 리눅스를 포함한 Unix를 이어받은 운영 체제는 LF (line feed, 0x0A , \n )를 개행 문자, 즉 커서를 다음 줄의 시작으로 옮기는 문자로 이용한다. 하지만 표준에 정의 된 LF 의 동작은 커서를 다음 줄로 내리는 것일 뿐, 커서를 줄의 처음으로 이동하지 않는다. 파일을 항상 운영 체제에 종속적인 애플리케이션을 통해서만 접근한다면 표준과 다른 동작은 문제되지 않는다. 하지만 파일과 입출력의 구분이 없는 유닉스 계열에서 파일과 프로세스의 입출력이 상호작용할 때 이 차이는 문제될 수 있다. 이 차이를 다루기 위해서 터미널은 출력에 적절한 가공을 하여 출력한다. 이를 제어하기 위한 플래그가 POSIX.1 표준이 정의 하는 termios 구조체의 c_oflag 다. c_oflag 는 터미널이 받은 문자를 출력하기 전에 어떤 후처리를 할지에 대한 플래그다. c_oflag에서 가장 중요한 플래그는 OPOST 다. 이는 입력에 대한 후처리를 할지 말지에 대한 플래그로 OPOST 가 꺼져있으면 다른 플래그와 상관없이 터미널은 받은 문자열을 그대로 보여준다. 이 플래그를 끄는 경우는 거의 없다. 하지만 터미널을 텍스트를 보여주기 위한 용도가 아닌 바이너리 데이터를 전송하기 위해 사용하는 경우 끄는 것이 좋다. 터미널이 Unix 계열 운영 체제에서 원하는대로 동작할 수 있게 해주는 플래그는 ONLCR 이다. ONLCR 이 켜져 있으면 터미널은 출력을 해석할 때 NL 을 CRNL 로 해석한다. 즉, Unix에서도 ONLCR 이 꺼져있다면, LF 를 만났을 때, 다음 줄의 처음으로 이동하는 것이 아닌, 현재 위치의 다음 줄로 이동한다. Unix 계열 운영 체제에서 윈도우에서 만들어진 파일을 출력해야 할 경우, CRNL 을 NL 로 바꾸지 않고도 ONLCR 플래그를 끄는 것 만으로도 간단하게 출력할 수 있다. 이외에도 구형 Mac OS 처럼 동작하게 해주는 OCRNL 플래그나 탭문자( 0x09 , \t )를...

개행 문자는 멀티 플랫폼에서 작업하는 사람들을 귀찮게 하는 것 중 하나다. Mac OS, Windows, Linux는 모두 다른 문자를 개행 문자로 사용한다. 심지어 Mac OS는 과거 버전과 최신 버전에서의 동작이 또 다르다. 이번 글에서는 시스템별로 다른 개행 문자를 사용하는 원인을 살펴볼 것이다. ISO 6429 표준 에 따르면 LF (line feed, \n)는 커서를 현재 행을 유지하면서 다음 줄로 옮기고, CR (carriage return, \r)는 커서를 현재 라인의 처음으로 옮긴다. 우리가 원하는 개행 문자의 동작을 위해서는 CR 과 LF 를 함께 써야 한다. 이런 구분은 라인을 바꾸는 동작과, 커서를 처음으로 옮기는 동작이 구분된 초기 프린터나 타자기의 동작을 모방했기 때문이다. A B 즉, 표준에 따르면 " A\nB "라는 문자열은 위에 보인 예시대로 A 아래 바로 B 가 오는 것이 아니라, A 의 대각선 아래 B 가 와야 한다. 하지만 개행 문자로 CRLF 를 사용하는 시스템은 드물다. 지금은 스토리지가 매우 싼 자원이다. 하지만 과거에는 스토리지가 매우 비싼 자원이었다. 이 시절 시스템 설계자들은 개행 문자를 위해 2바이트나 할당하라는 것을 과도한 사치로 보았다. 결국 어떤 시스템 설계자는 LF 를 어떤 시스템 설계자는 CR 을 단독으로 개행 문자로 사용하기 시작했다. 그 와중에도 표준을 지키던 시스템이 있었다. 그중 하나는 CP/M 이라는 운영체계다. CP/M은 CR 과 LF 의 조합을 개행문자로 사용했다. 이는 단순히 표준을 지키고자 하는 의지 때문이 아니라, 과거 있었던 원격 터미널 장치와의 호환성을 유지하기 위한 전략적 선택이었다. 다른 말로 하면, 비싼 스토리지 비용을 감당하더라도 호환성을 유지해 시장을 장악하는 것이 유리하다는 판단이었다. 후에 나오는 몇몇 운영체제도 CP/M 과 같은 선택을 했고, 이 중 하나가 마이크로소프트의 MS-DOS였다. 이 선택이 지금까지 이어져 마이크로소프트의 ...

리눅스나 유닉스 같은 POSIX 시스템에서는 fork 를 이용해서 자신과 똑같은 프로세스를 만들 수 있다. 이때 fork 를 호출한 프로세스를 부모 프로세스 라고 하고, 새로 생성된 프로세스를 자식 프로세스 라고 부르는데, 자식 프로세스는 부모 프로세스의 모든 메모리를 복사한다. fork 는 그 뒤 exec 을 해서 다른 바이너리를 실행시키는 fork-exec 이 일반적인 사용법이다. 하지만 자식 프로세스 는 부모 프로세스 와 완전히 같은 메모리를 가지기 때문에, 스레드가 존재하지 않던 시절에는 exec 을 하지 않고 병렬 처리를 하기 위해서도 자주 사용되었다. 지금은 스레드를 사용하는 것이 더 사용하기 쉽고 가벼운 방식이기에 스레드를 병렬처리를 위해 스레드를 주로 사용하지만, 스레드보다 서로 간에 독립적이기 때문에 일을 분리하기 위해서 사용하기도 한다. 분명히 fork 는 없어서는 안 될 기능이지만 fork 에는 태생적 한계가 있다. 애초에 fork 는 스레드라는 개념이 존재하지 않던 시절에 만들어졌기 때문에 thread-safe 하지 않다. 따라서 멀티스레드 환경에서 사용하려면 조심해서 사용해야 한다. fork 가 멀티스레드 환경에서 문제를 일으키는 이유는 fork 가 부모 프로세스 의 메모리를 전부 복사하지만, fork 를 호출한 스레드를 제외한 나머지 스레드들은 죽어버리기 때문이다. 따라서 fork 를 호출한 스레드 이외의 스레드에서 획득한 자원은 아무것도 해제되지 않는다. 메모리 릭도 충분히 문제지만, 이는 단순한 메모리 릭만을 의미하지 않는다. fork 가 복사한 메모리에는 힙이나 스택 이외에 mutex 나 condition variable 들도 포함된다. 만약 mutex 나 condition variable 이 다른 스레드에서 사용된 채로 fork 된다면 해당 변수로 보호되는 critical section에는 다시는 진입할 수 없게 된다. 특히나 malloc 같은 thread-safe 한 함수는 대부분 내부적으로 글로벌한 m...