개요: 이 글은 대용량의 메모리를 요구하는 솔라리스 OS 어플리케이션이 어떻게 메모리 부족 현상 혹은 데드락을 유발하는 등의
현상 없이 서브 프로세스를 효과적으로 생성하는지에 대해 설명 합니다. 또한 어떻게 어플리케이션 메모리가 사용되는지에 대해 솔라리스와 리눅스 같은
다른 운영체제와 다른 점에 관련된 이슈들을 탐구해 봅니다.
전통적으로 유닉스에서 새로운 프로세스를 생성하는 방법은 오직 하나가 존재 합니다: fork() 시스템 호출을 이용하고
또한 보통 exec() 시스템 콜을 뒤이어 바로 호출함. fork()는 부모 프로세스의 주소공간 전체의
카피를 만들고 exec() 가 이 카피를 새로운 프로세스로 변환 시킵니다.
(주의: 솔라리스에서 스왑 공간 은 시스템에 설정된 물리적인 메모리와 디스크 스왑 공간의 조합을 설명하기 위해 사용 됩니다. 다른 유닉스 시스템에서 이 단어는 아마 swap space on disk,
의 뜻 혹은 backing store 라는 의미로 사용 될 것입니다. 혼동을 피하기 위해 필자는
Virtual Memory (VM) 를 physical memory plus disk swap space. 를 나타내기 위해 사용합니다)
일반적으로 fork/exec 방법은 꽤 잘 작동합니다. 그러나 몇몇 경우 그것은 명확한 이유 없이 메모리 부족 현상이 나타난다 거나 fork의 성능상의 문제점 등 몇가지 불이익을 가져 올 수 있습니다.
메모리 부족 현상(Out of Memory): 대용량 메모리 프로세스에서 fork() 시스템 콜은 부적당한 VM의 용량 때문에 호출이 실패할 수 있습니다. 왜냐하면 fork()
는 부모 메모리의 2배 정도의 용량을 요구하기 때문입니다. 이것은 fork() 후에 곧바로 exec() 를 호출하여 여분의 메모리를 할당 해제 하더라도 발생합니다. 이런 현상이 발생하면 어플리케이션은 보통 종료됩니다.
예를들어 64-비트 어플리케이션이 6 기가바이트의 VM을 사용하고 ls(1)
커맨드를 수행하기 위해 서브프로세스를 만들어야 한다고 해 봅시다. 부모 프로세스가 fork() 를 호출 했을때 오직 또 다른 6기가의 VM이 사용 가능할 때만 성공적으로 수행될 것입니다. 만약 시스템에 그만한 크기의 메모리가 사용가능하지 않다면(자주 발생하는 상황), fork()
는 ENOMEM 에러 코드와 함께 실패 할 것입니다. 당연히 ls(1) 커맨드는 6기가 정도의 메모리가 필요로 하지 않지만 fork()
는 알지 못합니다.
일반 어플리케이션 뿐만 아니라 썬의 고유 툴들도 똑같은 문제로 고생하고 있습니다. 예를 들어 dbx와 관련된 다음의 썬 RFE (request for enhancement) 를 참고 바랍니다: "4748951 dbx shell should use posix_spawn()
for non-builtin commands rather than fork(2)".
RFE 4748951 은 고객의 유틸리티가 dbx 를 사용하여 대용량의 코어 파일을 읽어 들일때 사용되는 스크립트내에 cut(1) 커맨드를 수행하는 부분에서 발생하였습니다. " cannot fork - try again
" 에러 메세지가 발생하여 dbx 가 종료 되었습니다. 조사한 결과
dbx 가 소용량의 커맨드인 cut(1) 을 실행하기 위해 fork/exec 를 호출 하면서 fork() 호출시에 VM이 부족하면서 발생 했습니다.
솔라리스 JVM은 현재 또한 동일한 문제로 고생하고 있습니다. 썬 RFE: "5049299 Use posix_spawn,
not fork, on S10 to avoid swap exhaustion".
Fork의 퍼포먼스 : fork() 호출은 퍼포먼스에 악영향을 끼칠 수 있습니다. fork() 가
COW (copy-on-write) 구문을 사용하면서 발전해 왔더라도 여전히 마찬가지 입니다. 여전히 부모에서 자식에게 전달되는 특정 용량의 메모리를 복사 하기 ?문입니다.이러한 카피 작업은 자식 프로세스가 exec() 호출에 의해 곧바로 다른 프로세스로 대체 될때에는 불필요한 작업입니다. 이러한 퍼포먼스 저하는 부모 프로세스가 많은 양의 매핑된 메모리 공간을 가지고 있을때 확연히 알아 볼 수 있습니다.
이러한 불이익 (예를 들어 메모리 부족 현상, fork의 좋지 않은 퍼포먼스)는 특히 부모 프로세스가 대용량의 메모리를 소비할 때에(근래에는 매우 흔하게 발생함) 그리고 메모리 요청이 솔라리스에서 처럼 VM의 예약이 요구 될때 중요한 문제가 됩니다,
fork() 가 exec() 에 뒤따라 바로 살행되는 fork/exec 모델의 단점을 다루기 위해 버클리 버젼의 유닉스(BDS)는 1980년대 초반에 vfork() 시스템 콜을 내놓았습니다. vfork(2) 는 부모 프로세스를 자식 프로세스에 카피하지 않습니다. 두 프로세스가 모두 부모의 가상 주소 공간을 공유 합니다; 부모 프로세스는 자식 프로세스가 종료 되거나 exec() 를 호출할때 까지 정지 상태로 들어 갑니다.
vfork(2) 시스템 콜 또한 솔라리스에 채용되어 있습니다. 오랜 시간이 지난후에 멀티쓰레딩(MT)이 가능해 지고 많이 사용되면서 vfork() 가 어플리케이션이 여러개의 쓰레드를 가지고 있을때 새로운 문제를 일으킬 수 있음이 밝혀 졌습니다: 데드락. 데드락은 동적링커 ld.so.1 이 필요한 심볼들을 해석하는 과정에서 발생할 수 있습니다. 특별히 만약 자식 프로세스가 외부의 함수
(exec() 같은)를 호출할때 프로시져 링크 테이블(Procedure Linkage Table(PLT)) 항목을 해석하기 위해 동적 링커가 실행 되면서 동적 링커가 뮤텍스 락을 얻을 수 있습니다. 이 락은 부모 프로세스의 다른 쓰레드가 이미 가지고 있습니다. 만약 이러한 일이 발생한다면 부모와 자식 프로세스 간에 데드락이 발생할 수 있습니다. 왜냐하면 부모 프로세스의 어떠한 쓰레드도 자식 프로세스가
exec() 혹은 exit() 가 수행되기 전까지 수행될 수 없기 때문입니다. 결과적으로 부모와 자식 프로세스 모두 행이 걸릴 것입니다.
posix_spawn(3C)의 소개(참고자료 [1]) 로 인해 솔라리스10에서 이러한 문제를 해결 할 수 있게 되었습니다. 이전 버젼의 솔라리스(솔라리스9과 솔라리스8 2/02)에서 system(3C) 과 popen(3C)
호출은 VM의 용량을 두배로 요구하지 않고도 데드락에서 안전하도록 만들어 졌습니다.
몇몇 운영체제, 특히 리눅스는 memory overcommit
이란 기능을 가지고 있습니다. 이것은 어플리케이션이 malloc() 혹은 다른 메모리 요구 인터페이스를 사용할 때, 운영체제가 항상 요구된 메모리의 스왑 스페이스를 예약하지 않고 NULL 포인터가 아닌 포인터를 리턴해 줍니다.
리눅스는 fork() 와 exec() 로 구현된 posix_spawn() 을 가지고 있습니다. 메모리 overcommit 정책때문에 (아래에 설명됨),
리눅스는 위에서 언급된 첫번째 문제로 인해 고생할 염려는 없을 것입니다: 대용량 프로세스가 fork()를 호출할때 발생하는 메모리 부족 현상. 그러나 memory
overcommit 기능은 그 고유의 심각한 문제점을 발생 시켰습니다. 아래의 "Memory
Overcommit" 토론에서 참고 바랍니다.
이쯤에서 솔라리스 혹은 다른 유닉스 시스템에서 서브프로세스를 안전하고 효과적으로 생성 할 수 있는 대안적인 방법에 대해 설명하려고 합니다. 메인 프로세스를 초기화 하는 동안 (쓰레드를 생성하거나 대용량의 메모리를 할당하기 전에) 개발자는 큰 부모 프로세스의 서브프로세스 생성을 담당하는 특수한 도우미 프로세스를 만들 수 있습니다. 부모 프로세스는 파이프나 다른 내부 프로세스 통신 메카니즘을 통해 서브프로세스를 만들도록 요청을 보낼 수 있고, 실행하도록 명령할 수 있습니다. 도우미 프로세스는 fork() 를 호출할때 메모리가 부족이 될 일이 없고 매우 빠릅니다. 왜냐하면 요구되는 메모리가 매우 작아서 안전하게 fork/exec
를 이용해 서브프로세스를 만들 수 있기 때문입니다.
위에서 소개한 대안의 단점은 추가적인 복잡성입니다. 이러한 방법을 사용하는 어플리케이션은 반드시 메인 프로세스가 종료 됐을때 도우미 프로세스가 종료 됐는지 반드시 확인해야 하고 도우미 프로세스와의 통신을 위해 MT-safe한 방법을 사용해야 합니다. 또한 도우미 프로세스를 사용하면 자식 프로세스와의 파일 디스크립터 공유가 힘듭니다. 차라리 대용량의 부모 프로세스에서 posix_spawn(),
popen(), 혹은 system() 을 곧바로 사용하는 것이 훨씬 쉬운 방법입니다.
C/C++ 어플레케이션에서 새로운 프로세스를 시작시키는데 가장 간단한 방법은
system(3C) 을 사용하는 것입니다. system() 호출은 쉘에 주어진 커맨드를 실행 하도록 합니다. system(3C) 멘페이지에서 자세한 사항을 확인 바랍니다. 이러한 인터페이스는 만약 쉘 커맨드를 수행하고 그것이 끝날때까지 기다리는 작업을 수행 할? 적합합니다.
새로운 프로세스를 생성하는 좀 더 강력한 인터페이스는 popen(3C) 입니다. 새로운 프로세스를 시작하는것에 추가하여 popen() 은 개발자가 주어진 쉘 커맨드의 결과를 캡춰 할 수 있도록 도와주고 이것을 여러가지 방법으로 다룰 수 있도록(예를 들어 파싱 같은) 해 줍니다. 자세한 설명은 popen(3C) 멘 페이지를 참고 바랍니다.
이러한 유연성과 더불어 popen() 호출은 멀티쓰레드 프로그램에서 system() 보다 안전합니다. system()
호출은 다른 쓰레드에 영향을 줄 수 있는 몇몇 시그널들을 변형 시키지만
popen() 은 그렇지 않습니다. 이것이 popen(3C) 멘페이지에 MT-Safe 를 표기한 이유 입니다. system(3C) 에는 MT-unsafe가 표기되어 있습니다. system(3C) 멘 페이지를 참고 바랍니다.
이러한 기능을 하는 인터페이스 중에 가장 강력한 것은 솔라리스10에서 소개된 posix_spawn(3C)
(그리고 비슷한 posix_spawnp(3C)) 입니다. 이것은fork() 와 exec() 에서 할 수 있는 추가적인 수정 작업을 할 수 있도록 해 줍니다.
posix_spawn() 인터페이스는 개발자에게 자식 프로세스가 실행시킬 실행 파일의 전체 경로를 명시하도록 요구 합니다. posix_spawnp()
도 동일한 일을 하지만 조금 다르게 경로가 주어지지 않은체 파일명만 제공 됐을때 $PATH 디렉토리들에서 실행 파일을 직접 검색합니다.
아래에 posix_spawn()
인터페이스를 사용한 두가지의 예제 프로그램을 제공 합니다. posix_spawn(3C)
멘 페이지에 어떠한 예제도 제공하고 있지 않고 posix_spawn()
의 사용법 또한 꽤 복잡하기 때문에 아래의 예제들은 매우 유용할 것입니다.
이 예제는 간단한 쉘 커맨드를 수행하려는 간단한 목적으로 posix_spawn() 을 호출 하는 방법을 보여 줍니다(여기에서는 /bin/ls -l /etc/passwd)
그리고 커맨드가 종료 될때 까지 기다립니다. posix_spawn() 에서 발생하는 에러를 어떻게 체크하는지 주의 깊게 보시기 바랍니다.
이 예제는 fork()와 exec() 에서 자주 이루어 지는 수정작업을 어떻게 posix_spawn() 을 통해 수행하는지 보여 줍니다. 또한 파일 리다이렉션을 위해 쉘이 하는 작업을 유사하게 따라합니다. 프로그램은 특정한 파일과 연결된 표준 출력을 가지고 있는 자식 프로세스를 부모의 열린 파일 디스크립터에 방해를 주지 않고 생성 합니다. 간단한 예를 위해 /bin/cat 을 자식 프로세스로 사용 합니다.
posix_spawn_example2.c 예제 프로그램은
posix_spawn() 와 fork()/exec() 모두의 사용 예를 보여주고 인터페이스를 비교할 수 있도록 해 줍니다.
만약 -spawn 매개 변수로 실행 시키면 posix_spawn_example2.c
는 posix_spawn() 를 사용하고 자식 프로세스의 출력을 /etc/hosts 로 바인딩 시킵니다.
만약 매개 변수 없이 실행 시키면 posix_spawn_example2.c 는 fork()/exec()
를 사용하고 자식 프로세스의 출력을 /etc/passwd 로 바인딩 시킵니다 .
디버거가 없어도 truss(1) 를 이용해서 경로를 검사할 수 있습니다.
실제로 솔라리스10에서 fork() 옵션은 fork1() 을 호출하고 posix_spawn() 실행 경로는 vfork() 를 호출합니다
(그것의 libc-internal 버젼).
알아두어야 할점은 posix_spawn_example2.c 가 어떻게 에러 검출을 수행하는지 입니다. 이 것은 posix_spawn() 와 관련된 각 함수들에서 리턴되는 에러 코드를 검사 합니다.
또한 자식 프로세스에 문제가 생겼을때 리턴되는 에러 코드 127을 체크 합니다. posix_spawn(3C)
멘 페이지의 ERRORS 섹션을 확인 바랍니다. (자식 프로세스가 에러코드 127을 리턴하고 종료 됐을때에 대한 자세한 정보는 참고자료 [1]) 을 참고 바랍니다)
이러한 예제들은 대부분의 경우에서 사용하기에 충분한 posix_spawn()의
간단한 기능들을 어떻게 사용하는지에 대해 잘 보여 줍니다. 이것 외에도 posix_spawn() 은 유저와 그룹 ID 변경, 시그널 마스크 변경, 스케줄 클래스 변경 같은 약간 복잡한 수정을 가할수도 있도록 되어 있습니다. posix_spawn()
멘 페이지에서 자세한 사항을 확인하시기 바랍니다.
이러한 인터페이스들은 다양한 방법으로 구현될 수 있습니다. 가장 확실한 방법은 fork() 후에 바로 exec() 를 수행 하는 것입니다. 몇몇 운영체제는 이런식으로 동작합니다. 그러나 참고자료 [2] 에서는 fork() 대신에 vfork() 를 호출 하여 리눅스의 posix_spawn()의 구현을 향상시키는 요구에 대해 설명한 글입니다.
솔라리스10의 posix_spawn() 부터 시작해서 (그리고 Solaris 8 2/02 에 포함된 system() 과 popen()), 솔라리스의 이 3가지 인터페이스들은 절대로 데드락을 생성하지 않습니다. 그리고 대용량 어플리케이션의 스왑 부족현상을 유발하지도 않을 것입니다.
솔라리스10에서 posix_spawn() 은 현재 private-to-libc vfork(), execve(), 그리고 exit()
함수들을 이용해서 구현되어 있습니다. 이것들은 기능적인 면에서 일반 vfork(), execve(),
그리고 exit() 함수 들과 동일합니다. 그러나 이것들은 libc에서 추출되지 않았기 때문에 vfork() 가 libc 외부의 멀티쓰레드 코드에서 호출됨으로써 발생하는 동적링커프로그램에서의 데드락을 발생시키지 않습니다.
솔라리스10 버젼의 system(3C) 와 popen(3C)
은 posix_spawn() 를 이용해서 구현되었습니다. 솔라리스9과 솔라리스8 2/02 버젼의 인터페이스들은 private-to-libc
vfork() 와 execve() 를 이용하여 구현되었습니다.
이제 솔라리스는 오픈소스화 되었습니다. 그러므로 구현에 대한 자세한 정보는 다음의 예제에서 확인 가능합니다:
물론 솔라리스의 posix_spawn() 구현은 그것을 좀 더 효율적으로 만들기 위해 미래에 변경될 수 있습니다. 그러나 새로운 구현이 나오더라도 항상 표준 API를 제공할 것입니다.
알아두어야 할 점은 posix_spawn() 는 유닉스 표준의 한 요구사항 입니다.
버젼 3 (SUSv3), 참고자료 [3] 참조.
vfork(2) 시스템 콜 자체는 MT-safe 하게 만들어 질 수 없습니다. 그리고 더이상 필요로 하지도 않습니다. 솔라리스에서 vfork(2) 는 잘 쓰이지 않습니다. 멘 페이지에 따르면 "exec 계열이 수행 되기 전에 vfork가 독립적으로 수행하는 모든 작업은 안전하게 posix_spawn(3C)
혹은 posix_spawnp(3C) 에 의해 수행될 수 있습니다. "
몇몇 운영체제 (리눅스, IBM AIX, HP-UX 같은) 들은
memory overcommit 이라는 기능을 가지고 있습니다.( lazy swap allocation 이라고도 불림) memory
overcommit 모드에서 malloc() 은 스왑스페이스를 예약하지 않고 시스템에 충분한 VM이 있든 없든 항상 NULL 이 아닌 포인터를 리턴 합니다.
memory overcommit 기능은 다음과 같은 장점과 단점을 가지고 있습니다.
장점
fork() 호출이 VM의 부족으로 인해 실패 하지 않습니다.
시스템 메모리가 좀더 유동적이고 효율적으로 사용될 수 있습니다. 특히 어플리케이션이 동적으로 대용량의 메모리를 할당하고 거기에 데이타를 많이 채워 넣지 않을때 효과 적입니다.
memory overcommit 은 확장이 가능한 (무한적으로 큰) 배열과 메모리 버퍼에서 사용 될 수 있습니다;
참고자료 [4] 의 "Virtual Memory Arrays for Application Software"와 비교 바람.
위에서 설명한 확장 가능한 배열에 따라 많은 포트란 프로그램들 (특별히 Fotran-90 이전에 제작된 것들) 은 동적 메모리 할당을 사용하지 않습니다. 왜냐하면 초기 Fortran 버젼에서는 어떠한 표준 설비도 제공하지 않았기 때문 입니다. 대신 매우 큰 배열 선언자를 가지고 있었습니다. 그러나 이러한 배열의 부분만을 사용할 수 있었습니다. non-overcommit 시스템에서 이러한 Fortran 프로그램들은 전혀 로드하지 않거나 혹은 오직 개발자가 전혀 사용되지 않은 스왑스페이스를 위한 디스크 스페이스에 많은 부분을 소비 할 때만 로드합니다.
단점
memory overcommit 기능은 malloc() 실패 구문을 변경시킵니다. 충실하게 malloc()
이 NULL을 리턴하는지 체크 하거나 의미있는 에러 메세지를 발생시키거나 이러한 것을 회피하는 방법들을 사용하는 것은 memory overcommit 이 사용될때에는 전혀 소용이 없습니다.
memory overcommit 의 사용은 malloc() 의 리턴값이 NULL 포인터가 될 수 없고 할당된 메모리가 반드시 필요시에 사용가능해야 하기 때문에 표준 C/C++ 규약을 어기고 있다는 논쟁이 존재합니다.
가장 중요한 점은 memory overcommit 시스템에 VM이 부족하다면 하나 혹은 그 이상의 프로세스가 악명 높은 OOM(out-of-memory) 프로레스 킬러에 의해 종료 됩니다. 이것은 특히 엔터프라이즈 클래스 환경에서 용납되지 않을 수 있습니다. 다른 사용자의 어플리케이션이 너무 많은 VM을 사용한다고 해서 다른 사용자들의 어플레케이션을 종료 하는 것은 올바른 방법이 아닙니다.
이러한 이슈에 대한 재미있는 비유가 "Respite from the
OOM killer," 에 묘사되어 있습니다. 참고자료 [5] 를 참고 바랍니다(관련된 이슈들에 대한 자료도 있음). "An aircraft
company discovered ..." 으로 시작되는 문장을 찾아보시기 바랍니다.
리눅스 문서는 이러한 이슈를 반대로 생각 합니다. 레드햇은 그것을 다음의 글에서설명하고 있습니다: "Understanding Virtual Memory"
(참고자료 [6]), overcommit_memory
파라미터에 대한 설명을 포함함. "overcommit_memory is a value
..."로 시작하는 문단을 참고 바랍니다.
위의 레드햇 문서에 overcommit_memory 에 대한 설명과 리눅스 문서에 있는 설명을 비교하시기 바랍니다. 참고자료 [7] 참조. "The Linux kernel supports the following
overcommit handling modes."으로 시작하는 문단을 참조 바랍니다.
리눅스 커널 버젼 2.6과 그후에 버젼에서는 이론적으로 커널의 동작을 수정할 수 있는 방법이 존재 합니다. 그러므로 overcommit memory 가 발생하지 않을 것입니다. 이것은 strict overcommit mode 을 sysctl을 통해 조정함으로써 가능합니다:
sysctl -w vm.overcommit_memory=2
혹은 동일한 의미를 가지고 있는 vm.overcommit_memory=2 을 /etc/sysctl.conf 에 삽입합니다.
모드 2 (2.6의 새로운 기능) 은 현재 예전의 리눅스 커널에서 사용 가능한 모드 0, 1의 향상된 버젼입니다. 그러나 모드 2가 memory overcommit 이 발생하지 않음을 의미하는 것은 아닙니다. 단지 얼마나 많은 양의 메모리가 할당되도 안전한지 견고한 예측 방법만을 사용할 뿐입니다.
한가지 더 주의할 점은 vm.overcommit_memory=2 은 기본 설정 값이 아닙니다. 기본 설정값은 vm.overcommit_memory=0 입니다.
대조적으로 솔라리스에서 어플리케이션이 malloc()
을 호출할때(내부적으로는 sbrk(2) 를 호출 하여 메모리를 얻어옴),
커널은 사용 가능한 메모리 리스트를 검색하여 요구된 양의 VM이 사용 가능한지 알아 봅니다. 만약 발견 되었다면 커널은 메모리의 포인터를 호출 하고 스왑 공간을 예약하여 다른 프로세스가 그 공간을 사용하지 못하도록 합니다. 사용 가능한 메모리를 발견하지 못하면 malloc() 은 NULL을 리턴합니다.
솔라리스는 어떠한 종류의 견고한 예측 기능도 사용하지 않습니다. 그러므로 메모리가 부족할때 절대 임의적으로 다른 프로세스를 종료 시키지 않습니다.
솔라리스가 malloc()
혹은 sbrk() 를 이용할때 memory overcommit 을 이용하지는 않지만 mmap(MAP_NORESERVE) 을 통해 좀더 제어성을 가지고 정밀성을 높인 비슷한 기능을 사용 합니다. mmap(MAP_NORESERVE) 을 이용하여 개발자는 이 설비를 오직 특정하게 선택된 메모리 버퍼 혹은 어플리케이션에만 사용이 가능합니다. 좀 더 자세한 내용은 참고자료
[4]의 "Virtual Memory Arrays for Application "을 참고 바랍니다.
posix_spawn(3C) 인터페이스는 솔라리스10에서 소개되었습니다. 만약 어플리케이션이 빌드 되고 posix_spawn(3C) 가 사용가능하지 않은 솔라리스의 이전 버젼에서 수행되도록 하길 원한다면 다음과 같은 방법을 사용 합니다.
어플리케이션은 dlsym(RTLD_NEXT,"posix_spawn"))을 이용하여 동적으로 posix_spawn()이 사용 가능한지 알 수 있습니다. 예를 들어:
#include <dlfcn.h>
int (*posix_spawn_ptr)();
...
posix_spawn_ptr = (int(*)())dlsym(RTLD_NEXT, "posix_spawn");
if(posix_spawn_ptr != NULL)
{
/* Call posix_spawn_ptr() the same way as posix_spawn() */
}
else
{
/* posix_spawn() is not available; use older methods */
}
그러나 이러한 범용적인 방법을 쓰는데에는 문제가 있을 수 있습니다.
posix_spawn(3C) 은 다음과 같이 spawn.h
을 인클루드 시켜야 하기 ?문입니다:
#include <spawn.h>
만약 솔라리스9 혹은 그 이전 버젼에서 spawn.h 가 사용 가능하지 않지 않습니다. 이러한 문제를 회피하기 위해서 위의
#include <spawn.h> 구문을 다음과 같이 변경합니다:
/*
* To allow compiling such a program under Solaris 9 or earlier,
* copy /usr/include/spawn.h from Solaris 10
* locally and explicitly add definition of _RESTRICT_KYWD.
* Note that "spawn.h" is included, rather than <spawn.h>.
*/
#if (defined(__STDC__) && defined(_STDC_C99))
#define _RESTRICT_KYWD restrict
#else
#define _RESTRICT_KYWD
#endif
#include "spawn.h"
결과 프로그램은 솔라리스10 혹은 그 이전 버젼에서도 성공적으로 컴파일 될 것입니다.
주의할 점으로 솔라리스10의 헤더 파일의 카피를 가지고 있는 것은 spawn.h 가 변경 될 수도 있기 때문에 추가적인 관리 노력이 필요 합니다. 솔라리스10 혹은 그 후 버젼에서 어플리케이션을 빌딩할때에는 spawn.h 의 카피본을 제거 하고 위의 특별한 트릭을 이용하는 것이 좋습니다. 그리고 시스템 버젼의 spawn.h 을 대신 직접적으로 이용하는 것이 좋습니다. 개발자는 이러한 특수한 코드에 커멘트를 달아서 후에 다른 개발자들이 왜 spawn.h 의 복사본을 어플리케이션에서 사용했는지 알게 하는 것이 좋습니다.
