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

비밀번호

댓글 작성자
 




... 46  47  48  49  50  51  52  53  54  55  56  57  58  [59]  60  ...
NoWriterDateCnt.TitleFile(s)
12172정성태3/7/202016302개발 환경 구성: 474. docker - container에서 root 권한 명령어 실행(sudo)
12171정성태3/6/202011372VS.NET IDE: 143. Visual Studio - ASP.NET Core Web Application의 "Enable Docker Support" 옵션으로 달라지는 점 [1]
12170정성태3/6/20209904오류 유형: 599. "Docker Desktop is switching..." 메시지와 DockerDesktopVM CPU 소비 현상
12169정성태3/5/202011928개발 환경 구성: 473. Windows nanoserver에 대한 docker pull의 태그 사용 [1]
12168정성태3/5/202012637개발 환경 구성: 472. 윈도우 환경에서의 dockerd.exe("Docker Engine" 서비스)가 Linux의 것과 다른 점
12167정성태3/5/202011872개발 환경 구성: 471. C# - 닷넷 응용 프로그램에서 DB2 Express-C 데이터베이스 사용 (3) - ibmcom/db2express-c 컨테이너 사용
12166정성태3/4/202011481개발 환경 구성: 470. Windows Server 컨테이너 - DockerMsftProvider 모듈을 이용한 docker 설치
12165정성태3/2/202011110.NET Framework: 900. 실행 시에 메서드 가로채기 - CLR Injection: Runtime Method Replacer 개선 - 네 번째 이야기(Monitor.Enter 후킹)파일 다운로드1
12164정성태2/29/202011988오류 유형: 598. Surface Pro 6 - Windows Hello Face Software Device가 인식이 안 되는 문제
12163정성태2/27/202010448.NET Framework: 899. 익명 함수를 가리키는 delegate 필드에 대한 직렬화 문제
12162정성태2/26/202013282디버깅 기술: 166. C#에서 만든 COM 객체를 C/C++로 P/Invoke Interop 시 메모리 누수(Memory Leak) 발생 [6]파일 다운로드2
12161정성태2/26/20209888오류 유형: 597. manifest - The value "x64" of attribute "processorArchitecture" in element "assemblyIdentity" is invalid.
12160정성태2/26/202010610개발 환경 구성: 469. Reg-free COM 개체 사용을 위한 manifest 파일 생성 도구 - COMRegFreeManifest
12159정성태2/26/20208707오류 유형: 596. Visual Studio - The project needs to include ATL support
12158정성태2/25/202010616디버깅 기술: 165. C# - Marshal.GetIUnknownForObject/GetIDispatchForObject 사용 시 메모리 누수(Memory Leak) 발생파일 다운로드1
12157정성태2/25/202010598디버깅 기술: 164. C# - Marshal.GetNativeVariantForObject 사용 시 메모리 누수(Memory Leak) 발생 및 해결 방법파일 다운로드1
12156정성태2/25/20209876오류 유형: 595. LINK : warning LNK4098: defaultlib 'nafxcw.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
12155정성태2/25/20209115오류 유형: 594. Warning NU1701 - This package may not be fully compatible with your project
12154정성태2/25/20208906오류 유형: 593. warning LNK4070: /OUT:... directive in .EXP differs from output filename
12153정성태2/23/202011686.NET Framework: 898. Trampoline을 이용한 후킹의 한계파일 다운로드1
12152정성태2/23/202011415.NET Framework: 897. 실행 시에 메서드 가로채기 - CLR Injection: Runtime Method Replacer 개선 - 세 번째 이야기(Trampoline 후킹)파일 다운로드1
12151정성태2/22/202011866.NET Framework: 896. C# - Win32 API를 Trampoline 기법을 이용해 C# 메서드로 가로채는 방법 - 두 번째 이야기 (원본 함수 호출)파일 다운로드1
12150정성태2/21/202011748.NET Framework: 895. C# - Win32 API를 Trampoline 기법을 이용해 C# 메서드로 가로채는 방법 [1]파일 다운로드1
12149정성태2/20/202011525.NET Framework: 894. eBEST C# XingAPI 래퍼 - 연속 조회 처리 방법 [1]
12148정성태2/19/202012801디버깅 기술: 163. x64 환경에서 구현하는 다양한 Trampoline 기법 [1]
12147정성태2/19/202011435디버깅 기술: 162. x86/x64의 기계어 코드 최대 길이
... 46  47  48  49  50  51  52  53  54  55  56  57  58  [59]  60  ...