Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 5개 있습니다.)

윈도우 개발자를 위한 리눅스 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
"""

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가 더 사용하게 된 것인지도 모르겠습니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 7/11/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 16  17  [18]  19  20  21  22  23  24  25  26  27  28  29  30  ...
NoWriterDateCnt.TitleFile(s)
13190정성태12/9/20226828.NET Framework: 2076. C# - SynchronizationContext 기본 사용법파일 다운로드1
13189정성태12/9/20227598오류 유형: 831. Visual Studio - Windows Forms 디자이너의 도구 상자에 컨트롤이 보이지 않는 문제
13188정성태12/9/20226265.NET Framework: 2075. C# - 직접 만들어 보는 TaskScheduler 실습 (SingleThreadTaskScheduler)파일 다운로드1
13187정성태12/8/20226199개발 환경 구성: 654. openssl - CA로부터 인증받은 새로운 인증서를 생성하는 방법 (2)
13186정성태12/6/20224771오류 유형: 831. The framework 'Microsoft.AspNetCore.App', version '...' was not found.
13185정성태12/6/20225729개발 환경 구성: 653. Windows 환경에서의 Hello World x64 어셈블리 예제 (NASM 버전)
13184정성태12/5/20224972개발 환경 구성: 652. ml64.exe와 link.exe x64 실행 환경 구성
13183정성태12/4/20224894오류 유형: 830. MASM + CRT 함수를 사용하는 경우 발생하는 컴파일 오류 정리
13182정성태12/4/20225684Windows: 217. Windows 환경에서의 Hello World x64 어셈블리 예제 (MASM 버전)
13181정성태12/3/20225047Linux: 54. 리눅스/WSL - hello world 어셈블리 코드 x86/x64 (nasm)
13180정성태12/2/20225144.NET Framework: 2074. C# - 스택 메모리에 대한 여유 공간 확인하는 방법파일 다운로드1
13179정성태12/2/20224484Windows: 216. Windows 11 - 22H2 업데이트 이후 Terminal 대신 cmd 창이 뜨는 경우
13178정성태12/1/20225026Windows: 215. Win32 API 금지된 함수 - IsBadXxxPtr 유의 함수들이 안전하지 않은 이유파일 다운로드1
13177정성태11/30/20225749오류 유형: 829. uwsgi 설치 시 fatal error: Python.h: No such file or directory
13176정성태11/29/20224626오류 유형: 828. gunicorn - ModuleNotFoundError: No module named 'flask'
13175정성태11/29/20226354오류 유형: 827. Python - ImportError: cannot import name 'html5lib' from 'pip._vendor'
13174정성태11/28/20224841.NET Framework: 2073. C# - VMMap처럼 스택 메모리의 reserve/guard/commit 상태 출력파일 다운로드1
13173정성태11/27/20225581.NET Framework: 2072. 닷넷 응용 프로그램의 스레드 스택 크기 변경
13172정성태11/25/20225353.NET Framework: 2071. 닷넷에서 ESP/RSP 레지스터 값을 구하는 방법파일 다운로드1
13171정성태11/25/20224965Windows: 214. 윈도우 - 스레드 스택의 "red zone"
13170정성태11/24/20225228Windows: 213. 윈도우 - 싱글 스레드는 컨텍스트 스위칭이 없을까요?
13169정성태11/23/20225817Windows: 212. 윈도우의 Protected Process (Light) 보안 [1]파일 다운로드2
13168정성태11/22/20225120제니퍼 .NET: 31. 제니퍼 닷넷 적용 사례 (9) - DB 서비스에 부하가 걸렸다?!
13167정성태11/21/20225186.NET Framework: 2070. .NET 7 - Console.ReadKey와 리눅스의 터미널 타입
13166정성태11/20/20224930개발 환경 구성: 651. Windows 사용자 경험으로 WSL 환경에 dotnet 런타임/SDK 설치 방법
13165정성태11/18/20224828개발 환경 구성: 650. Azure - "scm" 프로세스와 엮인 서비스 모음
... 16  17  [18]  19  20  21  22  23  24  25  26  27  28  29  30  ...