윈도우 개발자를 위한 리눅스 fork 동작 방식 설명 (파이썬 코드)
fork는 리눅스 전용 API입니다. 그래서 윈도우 환경에서 (제아무리 파이썬이 다중 플랫폼을 지원한다지만) 다음의 스크립트를 실행하면,
# 파이썬 예제
import os
pid = os.fork()
이런 오류가 발생합니다.
e:\Python37\python.exe D:/pycharm/work/testconsole/main.py
Traceback (most recent call last):
File "D:/pycharm/work/testconsole/main.py", line 9, in <module>
pid = os.fork()
AttributeError: module 'os' has no attribute 'fork'
Process finished with exit code 1
이와 유사하게,
gunicorn이 윈도우에서 동작하지 않는 이유가 *nix 전용 라이브러리인 fcntl을 사용해서 그런 것입니다.
따라서, os.fork가 사용된 파이썬 스크립트를 사용하려면 WSL 환경과의 연동이 꼭 필요합니다.
PyCharm - 윈도우 환경에서 WSL을 이용해 파이썬 앱 개발/디버깅하는 방법
; https://www.sysnet.pe.kr/2/0/12789
그런데, 왜 fork가 윈도우에서는 구현할 수가 없는 걸까요? 이에 대해선 fork의 동작 원리를 먼저 알아야 합니다.
우선, fork는 스레드가 없던 시절의 기능으로 나름 스레드와 같은 저비용의 멀티태스킹을 구현하기 위해 나온 API입니다. 윈도우 개발자들에게는 어쩔 수 없이 '스레드'라는 표현을 쓰게 되었지만, 사실 fork는 스레드와 전혀 무관하고 단순히 "프로세스 복제"라고 이해하시면 되는데 윈도우 운영체제에는 없는 개념입니다.
굳이 윈도우 개발자들에게 설명하자면, fork를 다음과 같이 생각하면 됩니다.
fork = 현재 프로세스의 복제
≑ 메모리 복사 + CreateProcess(this) + 스레드 IP 위치를 현재의 fork 코드 다음으로 설정
재미있죠? ^^ 그런데, 얼핏 메모리 복사와 CreateProcess라고 하니 굉장히 무거운 동작이 될 거라고 생각할 수 있지만 사실 가볍게 처리할 수 있습니다. 왜냐하면 "메모리 복사"를 무조건 다 하는 것이 아니라, fork로 생성된 child 프로세스는 기본적으로 부모 프로세스의 메모리를 링크로 가리키는 방식으로 복제되기 때문입니다.
그런 다음, parent와 child 간의 프로세스가 공유 메모리를 변경하는 일이 발생하면 그때에만 한정해서 Copy-on-write 방식으로 해당 페이지 프레임을 복사 처리합니다. 따라서, 초기 CreateProcess 속도가 가벼울 수밖에 없습니다.
거기다 또 한 가지 특이한 것은, Child 프로세스의 실행 시작 위치가 (윈도우라면 WinMain/DllMain 함수가 아니라) 현재 fork API가 호출된 바로 그다음 위치를 가리킨다는 점입니다. (말 그대로 스레드 콜 스택 및 문맥까지도 모두 포함한 메모리 복제이므로 가능한 것입니다.)
이처럼, 메모리 복제와 스레드 시작 위치를 조정하는 2가지 이유 때문에 윈도우 운영체제에서는 os.fork 함수를 CreateProcess로 대체할 수 없어 지원이 안 되는 것입니다.
자, 이렇다 보니 os.fork 이후 스레드의 흐름이 재미있어집니다. 만약 다음과 같은 식으로 코딩을 하면,
os.fork()
print('Hello world')
부모와 자식 프로세스가 모두 os.fork 이후의 코드를 실행하므로 화면에는 둘다 "Hello world"가 출력될 것입니다. 그런데, 여기서 문제는 부모와 자식이 각각 다른 코드를 실행하고 싶을 때입니다. 윈도우의 경우라면 CreateThread에서 스레드 시작 함수 위치를 함께 넘겨주므로 이런 고민이 없지만, fork의 경우에는 명시적인 스레드 함수를 지정하는 것이 아니므로 이것을 다른 방법을 이용해 해결해야만 합니다.
바로 그 방법이란 게, os.fork가 반환하는 값을 이용하는 것입니다.
pid = os.fork();
# pid 값
# 1) os.fork를 실행한 부모 프로세스의 경우: pid == 자식 프로세스의 ID
# 2) 새로 생성된 자식 프로세스의 경우: pid == 0
(아마도 os.fork를 호출한 것이 아닌, 그 이후의 코드에서부터 실행한다는 의미에서 0으로 초기화하는 듯)
따라서, 부모/자식 프로세스 간에 별도의 흐름을 타고 싶다면 이런 식으로 처리하게 됩니다.
pid = os.fork();
if pid > 0:
print('부모 프로세스의 실행 흐름', os.getpid())
elif pid == 0:
print('자식 프로세스의 실행 흐름', os.getpid())
else: # pid < 0
print('fork 오류')
print('모두 호출', os.getpid())
위의 경우 부모 프로세스는 다음과 같이 출력하고,
부모 프로세스의 실행 흐름 4793
모두 호출 4793
자식 프로세스는 이렇게 출력합니다.
자식 프로세스의 실행 흐름 4794
모두 호출 4794
그런데, 보통 fork 이후에는 부모 또는 자식 프로세스의 흐름에서 execl 함수를 호출하는 것을 볼 수 있습니다.
pid = os.fork();
if pid > 0:
print('부모 프로세스의 실행 흐름', os.getpid())
elif pid == 0:
os.execl(sys.executable, sys.executable, 'calc.py')
else: # pid < 0
print('fork 오류')
print('모두 호출', os.getpid())
""" 출력 결과
부모 프로세스의 실행 흐름 4802
모두 호출 4802
"""
(일반적을 exec로 퉁치는) execl 역시 윈도우 운영체제에서는 지원되지 않는 함수인데요, 특이하게도 이것은 현재 프로세스의 공간에 인자로 들어온 바이너리 이미지를 덮어 쓰는 역할을 합니다. 따라서, 위의 코드에서는 os.execl 호출 이후 더 이상 자식 프로세스의 "모두 호출" 코드가 보이지 않게 됩니다.
사실 위의 코드들이 복잡해서 그렇지 Windows 운영체제라면 위의 코드에 한해서 다음과 같이 간단하게 변환이 가능합니다.
CreateProcess("/usr/bin/python3", "calc.py", ...);
printf("모두 호출");
단지, execl을 호출하지 않는다면 그에 대한 실행 흐름을 윈도우에서는 흉내 낼 수 없어 결국 os.fork (및 execl)에 대한 지원을 할 수 없게 된 것입니다.
참고로, execl로 현재 자식 프로세스를 덮어버리고 싶지 않다면 subprocess를 사용하는 것도 방법입니다.
import os
import subprocess
pid = os.fork()
if pid > 0:
print('부모 프로세스의 실행 흐름', os.getpid())
elif pid == 0:
print('자식 프로세스의 실행 흐름', os.getpid())
subprocess.Popen([sys.executable, 'calc.py'])
else: # pid < 0
print('fork 오류')
print('모두 호출', os.getpid())
이렇게 호출하면, 자식 프로세스의 흐름에서는 다시 그것의 자식 프로세스를 Popen 함수로 생성하고 제어를 반환받아 이후 "모두 호출" 출력을 하게 됩니다. (윈도우의 CreateProcess가 호출 후 제어를 바로 반환하는 것과 같습니다.)
그나저나 좀 아이러니하지 않나요? ^^ 다중 플랫폼 지원으로 유명한 자바의 경우에도 사실 fork API는 거의 사용하지 않습니다. 그래서 이런 문제로 인한 윈도우/리눅스 간의 포팅 문제는 희소할 것입니다. 반면, 보다 더 추상화했을 스크립트 언어인 파이썬에서 오히려 운영체제에 종속되는 API를 종종 사용하고 있는 것입니다. 아마도 파이썬 자체가 GIL(Global Interpreter Lock)이라는 제약으로 인해,
[python] GIL, Global interpreter Lock은 무엇일까?
; https://ssungkang.tistory.com/entry/python-GIL-Global-interpreter-Lock%EC%9D%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C
os.fork가 더 사용하게 된 것인지도 모르겠습니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]