Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

파이썬 - fork 시 기존 클라이언트 소켓 및 스레드의 동작

지난 글에 설명한 것처럼,

윈도우 개발자를 위한 리눅스 fork 동작 방식 설명 (파이썬 코드)
; https://www.sysnet.pe.kr/2/0/12811

fork는 현재 프로세스의 메모리 그대로 복사해 실행하는데, 그렇다면 해당 프로세스에서 이미 연결해 두었던 클라이언트 소켓은 어떻게 되는 걸까요? 이론상으로는 fork된 프로세스에서도 유효한 소켓 descriptor이기 때문에 부모 프로세스와 전혀 다르지 않게 통신을 해야 할 것입니다.

정말 그런지 테스트를 해볼까요? ^^

이를 위해 다음과 같이 간단하게 파이썬 예제 코드를 만들고,

import os
import socket
import struct
import time
from threading import Thread, Timer

log_socket = None


class LogSocket:
    def __init__(self, port, address=None):
        self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

        if address is None:
            address = "127.0.0.1"

        self.address = address
        self.port = port

        self.sock.connect((self.address, self.port))
        pid = os.getpid()
        buf = struct.pack('i', pid)
        self.sock.send(buf)

    def log(self, text):
        buf = struct.pack('i', len(text))
        self.sock.send(buf)

        self.sock.send(text.encode('utf-8'))

    def close(self):
        self.sock.close()


log_socket = LogSocket(39999)
pid = os.fork()

if pid > 0:
    print('부모 프로세스의 실행 흐름', os.getpid())
elif pid == 0:
    print('자식 프로세스의 실행 흐름', os.getpid())
else:  # pid < 0
    print('fork 오류')

while True:
    time.sleep(1)
    log_socket.log("current pid: " + str(os.getpid()))

(첨부 파일로 포함한 C# TCP 서버 프로그램을 마련한 후) 실행해 TCP 서버 측에서 수신하는 데이터를 보면,

$ python main.py
부모 프로세스의 실행 흐름 17120
자식 프로세스의 실행 흐름 17121

/*
pstree -p | grep main.py
*/

// TCP 서버 측 수신 데이터

current pid: 17120
current pid: 17121
...[이하 반복]...

단일 소켓 연결을 사용해 (fork 중인) 부모와 자식 프로세스 모두 TCP 서버와 통신하는 것을 확인할 수 있습니다.




fork로 인한 부모/자식이 소켓 하나를 공유해 사용하고 있지만, 네트워크의 특성을 고려해 저것이 2개로 나뉠 수 있다는 것을 감안해야 합니다.

가령, fork 이후 서버 측과의 소켓 통신이 끊겨서 재연결을 하는 경우라고 가정해 보겠습니다. 그렇다면, 기존에는 1개의 소켓을 공유했지만, 소켓이 끊기게 되면 이후 부모/자식 프로세스가 모두 각각 소켓 통신을 열게 되므로 2개의 소켓이 사용될 수 있습니다.

역시 간단하게 이전에 사용한 코드 중 LogSocket 관련 코드만 다음과 같이 바꾸고,

class LogSocket:
    def __init__(self, port, address=None):
        self.sock = None
        self.address = address
        self.port = port

        self.reconnect()

    def reconnect(self):
        self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

        if self.address is None:
            self.address = "127.0.0.1"

        self.sock.connect((self.address, self.port))
        process_id = os.getpid()
        buf = struct.pack('i', process_id)
        self.sock.send(buf)

    def log(self, text):

        try:
            buf = struct.pack('i', len(text))
            self.sock.send(buf)

            self.sock.send(text.encode('utf-8'))
        except:
            self.reconnect()

    def close(self):
        self.sock.close()

테스트하면, 최초 실행 시 1개의 소켓으로 공유하는 중에 서버 측에서 강제로 해당 연결을 끊어버리면 fork의 부모/자식 프로세스가 reconnect 함수를 각각 실행하면서 별도의 소켓 연결을 가져가게 됩니다.

사실, fork의 이런 동작은 전체적인 프로그램에 대한 코드 실행 경로를 자칫 난해하게 만들 수 있으므로 사용하는 유형이 정해져 있습니다. 대표적인 사례로 TCP 서버에서 클라이언트가 접속했을 때 해당 소켓과 통신하는 전용 프로세스를 fork로 만들어 떼어내는 것입니다.

또한 전에도 언급했지만, 파이썬의 경우 유독 GIL(Global Interpreter Lock)로 인해 fork와 친해질 수밖에 없는 구조입니다. 이로 인해 Django를 호스팅하는 uwsgigunicorn에서 요청이 오면 그것을 처리하기 위한 (별도 스레드가 아닌) fork로 자식 프로세스를 만들게 된 것입니다. (물론, gunicorn이라면 --worker-class=gthread 옵션이 있지만!)




그렇다면 스레드는 어떻게 될까요? 원칙상으로 보면, 소켓이나 스레드와 같은 커널 자원이 fork로 자식 프로세스에 복제되는 것은 엄밀히 핸들 값에 불과할 뿐입니다. 그렇기 때문에 소켓의 경우는 부모/자식에서 모두 사용할 수 있었지만, 스레드의 경우에는 fork된 자식 프로세스에서 딱히 역할을 하지 않습니다.

역시 간단하게 이전의 파이썬 코드에서 스레드만 추가해 다음과 같이 확인할 수 있습니다.

import os
import socket
import struct
import threading
import time
from threading import Thread, Timer

log_socket = None


class LogSocket:
    def __init__(self, port, address=None):
        self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

        if address is None:
            address = "127.0.0.1"

        self.address = address
        self.port = port

        self.sock.connect((self.address, self.port))
        pid = os.getpid()
        buf = struct.pack('i', pid)
        self.sock.send(buf)

    def log(self, text):
        buf = struct.pack('i', len(text))
        self.sock.send(buf)

        self.sock.send(text.encode('utf-8'))

    def close(self):
        self.sock.close()


def run_thread():
    def handler():
        global log_socket

        while True:
            log_socket.log("current pid: " + str(os.getpid()) + ", " + str(threading.get_native_id()))
            time.sleep(1)

    t = Thread(target=handler)
    t.daemon = True
    t.start()
    return t


log_socket = LogSocket(39999)
run_thread()

pid = os.fork()

if pid > 0:
    print('부모 프로세스의 실행 흐름', os.getpid())
elif pid == 0:
    print('자식 프로세스의 실행 흐름', os.getpid())
else:  # pid < 0
    print('fork 오류')

while True:
    time.sleep(1)

실행해 보면 파이썬 콘솔에는 2개의 프로세스 id가 보이고 TCP 서버에서는 단일 소켓으로 1초마다 들어오는 메시지를 확인할 수 있습니다.

$ python main.py
부모 프로세스의 실행 흐름 17109
자식 프로세스의 실행 흐름 17111

// TCP 서버 측 수신 데이터

current pid: 17109, 17110
current pid: 17109, 17110
...[이하 반복]...

pid를 보면 알겠지만, 부모 프로세스가 17109이고 그 프로세스에서 생성한 스레드가 17110, 마지막으로 fork 프로세스가 17111로 할당돼 있습니다.

(첨부 파일은 이 글에서 사용한 파이썬 예제 코드와 C# TCP 서버를 포함합니다.)




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







[최초 등록일: ]
[최종 수정일: 2/8/2023]

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

비밀번호

댓글 작성자
 




1  [2]  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13576정성태3/8/20241543닷넷: 2228. .NET Profiler - IMetaDataEmit2::DefineMethodSpec 사용법
13575정성태3/7/20241676닷넷: 2227. 최신 C# 문법을 .NET Framework 프로젝트에 쓸 수 있을까요?
13574정성태3/6/20241557닷넷: 2226. C# - "Docker Desktop for Windows" Container 환경에서의 IPv6 DualMode 소켓
13573정성태3/5/20241563닷넷: 2225. Windbg - dumasync로 분석하는 async/await 호출
13572정성태3/4/20241643닷넷: 2224. C# - WPF의 Dispatcher Queue로 알아보는 await 호출의 hang 현상파일 다운로드1
13571정성태3/1/20241620닷넷: 2223. C# - await 호출과 WPF의 Dispatcher Queue 동작 확인파일 다운로드1
13570정성태2/29/20241635닷넷: 2222. C# - WPF의 Dispatcher Queue 동작 확인파일 다운로드1
13569정성태2/28/20241545닷넷: 2221. C# - LoadContext, LoadFromContext 그리고 GAC파일 다운로드1
13568정성태2/27/20241606닷넷: 2220. C# - .NET Framework 프로세스의 LoaderOptimization 설정을 확인하는 방법파일 다운로드1
13567정성태2/27/20241618오류 유형: 898. .NET Framework 3.5 이하에서 mscoree.tlb 참조 시 System.BadImageFormatException파일 다운로드1
13566정성태2/27/20241631오류 유형: 897. Windows 7 SDK 설치 시 ".NET Development" 옵션이 비활성으로 선택이 안 되는 경우
13565정성태2/23/20241479닷넷: 2219. .NET CLR2 보안 모델에서의 개별 System.Security.Permissions 제어
13564정성태2/22/20241614Windows: 259. Hyper-V Generation 1 유형의 VM을 Generation 2 유형으로 바꾸는 방법
13563정성태2/21/20241645디버깅 기술: 196. windbg - async/await 비동기인 경우 메모리 덤프 분석의 어려움
13562정성태2/21/20241645오류 유형: 896. ASP.NET - .NET Framework 기본 예제에서 System.Web에 대한 System.IO.FileNotFoundException 예외 발생
13561정성태2/20/20241744닷넷: 2218. C# - (예를 들어, Socket) 비동기 I/O에 대한 await 호출 시 CancellationToken을 이용한 취소파일 다운로드1
13560정성태2/19/20241747디버깅 기술: 195. windbg 분석 사례 - Semaphore 잠금으로 인한 Hang 현상 (닷넷)
13559정성태2/19/20242624오류 유형: 895. ASP.NET - System.Security.SecurityException: 'Requested registry access is not allowed.'
13558정성태2/18/20241820닷넷: 2217. C# - 최댓값이 1인 SemaphoreSlim 보다 Mutex 또는 lock(obj)를 선택하는 것이 나은 이유
13557정성태2/18/20241620Windows: 258. Task Scheduler의 Author 속성 값을 변경하는 방법
13556정성태2/17/20241684Windows: 257. Windows - Symbolic (hard/soft) Link 및 Junction 차이점
13555정성태2/15/20241955닷넷: 2216. C# - SemaphoreSlim 사용 시 주의점
13554정성태2/15/20241709VS.NET IDE: 189. Visual Studio - 닷넷 소스코드 디컴파일 찾기가 안 될 때
13553정성태2/14/20241736닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
13552정성태2/13/20241692닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
13551정성태2/12/20242017닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
1  [2]  3  4  5  6  7  8  9  10  11  12  13  14  15  ...