PEP 734 – 표준 라이브러리의 다중 인터프리터

Author:

Eric Snow <ericsnowcurrently at gmail.com>

Discussions-To:

Discourse thread

Status:

Final

Type:

Standards Track

Created:

06-Nov-2023

Python-Version:

3.14

Post-History:

14-Dec-2023

Replaces:

554

Resolution:

05-Jun-2025

---

Table of Contents

• 개요
• 소개
  • 스레드 및 스레드 상태
  • 인터프리터 상태
  • 인터프리터와 스레드
  • “주” 인터프리터
  • 인터프리터 격리
  • 기존 실행 구성 요소
    • builtins.exec()
    • 명령줄
    • threading.Thread
• 동기
• 사양
  • 인터프리터 사용
  • 인터프리터 객체
  • 인터프리터 간 통신
  • 큐 객체
  • 공유 가능한 객체
  • 동기화
  • 예외
  • InterpreterPoolExecutor
  • sys.implementation.supports_isolated_interpreters
  • 예제
• 근거
  • 최소 API
  • create(), create_queue()
  • 인터프리터.prepare_main()은 여러 변수를 설정합니다.
  • 예외 전파
  • 객체와 ID 프록시
• 거부된 아이디어
• Copyright

번역·라이선스 안내

이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain or CC0-1.0, whichever is more permissive 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판

Important

This PEP is a historical document. The up-to-date, canonical documentation can now be found at concurrent.interpreters.

×

See PEP 1 for how to propose changes.

Note

이 PEP는 본질적으로 PEP 554의 연속입니다. 해당 문서는 7년에 걸친 논의 동안 부수적인 정보가 많이 추가되었습니다. 이 PEP는 핵심 정보로 다시 축약한 것입니다. 그러한 추가 정보의 상당 부분은 여전히 유효하고 유용하지만, 여기서 다루는 구체적인 제안의 직접적인 맥락에는 해당하지 않습니다.

Note

이 PEP는 이름을 concurrent.interpreters로 변경한다는 조건으로 승인되었습니다.

개요

이 PEP는 현재 프로세스에서 여러 인터프리터를 검사하고 생성하며 코드를 실행할 수 있도록 새로운 모듈인 interpreters를 추가할 것을 제안합니다. 여기에는 기본이 되는 인터프리터를 나타내는 Interpreter 객체가 포함됩니다. 또한 이 모듈은 인터프리터 간 통신을 위한 기본 Queue 클래스를 제공합니다. 마지막으로 interpreters 모듈을 기반으로 하는 새로운 concurrent.futures.InterpreterPoolExecutor를 추가합니다.

소개

근본적으로 “인터프리터”는 Python 스레드가 공유해야 하는 (본질적으로) 모든 런타임 상태의 집합입니다. 그러므로 먼저 스레드를 살펴보겠습니다. 그런 다음 인터프리터로 다시 돌아가겠습니다.

스레드 및 스레드 상태

Python 프로세스에는 Python 코드를 실행하거나 (또는 다른 방식으로 C API와 상호 작용하는) 하나 이상의 OS 스레드가 있습니다. 이러한 각 스레드는 자체 스레드 상태(PyThreadState)를 사용하여 CPython 런타임과 상호 작용하며, 이 상태에는 해당 스레드에 고유한 모든 런타임 상태가 저장됩니다. 여러 OS 스레드 간에 공유되는 런타임 상태도 있습니다.

어떤 OS 스레드든 현재 사용 중인 스레드 상태를 전환할 수 있지만, 다른 OS 스레드가 이미 사용 중이거나 사용한 상태여서는 안 됩니다. 이 “현재” 스레드 상태는 런타임에 스레드 로컬 변수로 저장되며, PyThreadState_Get()으로 명시적으로 조회할 수 있습니다. 이는 초기 (“주”) OS 스레드와 threading.Thread 객체에 대해 자동으로 설정됩니다. C API에서는 PyThreadState_Swap()으로 설정 및 (해제)되며, PyGILState_Ensure()로 설정할 수도 있습니다. 대부분의 C API는 현재 스레드 상태가 존재해야 하며, 이를 암묵적으로 조회하거나 인자로 전달해야 합니다.

OS 스레드와 스레드 상태의 관계는 일대다입니다. 각 스레드 상태는 최대 하나의 OS 스레드에 연결되며 해당 스레드 ID를 기록합니다. 스레드 상태는 둘 이상의 OS 스레드에 사용되는 일이 없습니다. 그러나 반대 방향으로는 하나의 OS 스레드에 둘 이상의 스레드 상태가 연결될 수 있지만, 다시 말해 현재 상태가 될 수 있는 것은 하나뿐입니다.

하나의 OS 스레드에 둘 이상의 스레드 상태가 있는 경우, 해당 OS 스레드에서 PyThreadState_Swap()을 사용하여 상태 사이를 전환하며, 요청된 스레드 상태가 현재 상태가 됩니다. 이전 스레드 상태를 사용하여 해당 스레드에서 실행 중이던 것은 그 스레드 상태가 다시 전환되어 들어올 때까지 사실상 일시 중지됩니다.

인터프리터 상태

앞서 언급했듯이, 여러 OS 스레드가 공유하는 일부 런타임 상태가 있습니다. 그중 일부는 sys모듈을 통해 노출되지만, 상당 부분은 내부적으로 사용되며 명시적으로 노출되지 않거나 C API를 통해서만 노출됩니다.

이 공유 상태를 인터프리터 상태(PyInterpreterState)라고 합니다. 여기서는 이를 때때로 단순히 “인터프리터”라고 부르지만, 이 용어는 python실행 파일, Python 구현, 바이트코드 인터프리터(즉, exec()/eval())를 가리키는 데에도 사용됩니다.

CPython은 버전 1.5(1997)부터 동일한 프로세스에서 여러 인터프리터(일명 “서브인터프리터”)를 지원해 왔습니다. 이 기능은 C API를 통해 사용할 수 있습니다.

인터프리터와 스레드

스레드 상태와 인터프리터 상태의 관계는 (높은 수준에서) OS 스레드와 프로세스의 관계와 거의 같은 방식으로 서로 연관되어 있습니다. 우선 이 관계는 일대다입니다. 스레드 상태는 하나의 인터프리터에 속하며, 해당 인터프리터를 가리키는 포인터를 저장합니다. 해당 스레드 상태는 다른 인터프리터에 절대로 사용되지 않습니다. 그러나 반대 방향으로는 하나의 인터프리터에 0개 이상의 스레드 상태가 연결될 수 있습니다. 인터프리터는 해당 인터프리터의 스레드 상태 중 하나가 현재 상태인 OS 스레드에서만 활성 상태로 간주됩니다.

인터프리터는 Py_NewInterpreterFromConfig() (또는 Py_NewInterpreterFromConfig()를 감싸는 간단한 래퍼인 Py_NewInterpreter())를 사용하는 C API를 통해 생성됩니다. 이 함수는 다음 작업을 수행합니다.

1. 새 인터프리터 상태를 생성합니다.
2. 새 스레드 상태를 생성합니다.
3. 스레드 상태를 현재 상태로 설정합니다(인터프리터 초기화에는 현재 tstate가 필요합니다).
4. 해당 스레드 상태를 사용하여 인터프리터 상태를 초기화합니다.
5. 스레드 상태를 반환합니다(여전히 현재 상태입니다).

반환된 스레드 상태는 즉시 폐기해도 된다는 점에 유의하십시오. 인터프리터를 실제로 사용하려는 순간까지는 인터프리터가 어떤 스레드 상태도 가지고 있어야 한다는 요구 사항이 없습니다. 그 시점에는 현재 OS 스레드에서 활성 상태로 만들어야 합니다.

기존 인터프리터를 현재 OS 스레드에서 활성 상태로 만들려면, C API 사용자는 먼저 해당 인터프리터에 대응하는 스레드 상태가 있는지 확인합니다. 그런 다음 해당 스레드 상태를 사용하여 일반적인 방식으로 PyThreadState_Swap()을 호출합니다. 다른 인터프리터의 스레드 상태가 이미 현재 상태였다면 일반적인 방식으로 교체되어 나가며, 따라서 해당 OS 스레드에서 그 인터프리터의 실행은 다시 교체되어 들어올 때까지 사실상 일시 중지됩니다.

이처럼 인터프리터가 현재 OS 스레드에서 활성 상태가 되면, 해당 스레드는 PyEval_EvalCode()(즉, exec())와 같은 C API의 모든 함수를 호출할 수 있습니다. 이는 현재 스레드 상태를 런타임 컨텍스트로 사용하여 동작합니다.

“주” 인터프리터

Python 프로세스가 시작되면 현재 OS 스레드에 대한 단일 스레드 상태와 함께 하나의 인터프리터 상태(“주” 인터프리터)를 생성합니다. 그런 다음 이를 사용하여 Python 런타임을 초기화합니다.

초기화 후 스크립트나 모듈 또는 REPL이 이를 사용하여 실행됩니다. 이 실행은 인터프리터의 __main__ 모듈에서 이루어집니다.

프로세스가 요청된 Python 코드 또는 REPL 실행을 마치면, 주 OS 스레드에서 주 인터프리터를 사용하여 해당 스레드에서 Python 런타임이 종료 처리됩니다.

런타임 종료 처리는 주 인터프리터에서 실행 중인 Python 스레드인지 서브인터프리터에서 실행 중인 Python 스레드인지와 관계없이, 아직 실행 중인 Python 스레드에 간접적으로 아주 약한 영향만 미칩니다. 이는 즉시 모든 비데몬 Python 스레드가 종료될 때까지 무기한 기다리기 때문입니다.

C API를 조회할 수는 있지만, threading._register_atexit()를 사용하여 등록되었을 가능성이 있는 “atexit” 함수 외에는 종료 처리가 시작되었다는 사실을 어떤 Python 스레드에도 직접 알리는 메커니즘이 없습니다.

남아 있는 서브인터프리터는 나중에 자체적으로 종료 처리되지만, 그 시점에는 어떤 OS 스레드에서도 현재 인터프리터가 아닙니다.

인터프리터 격리

CPython의 인터프리터는 서로 엄격하게 격리되도록 설계되었습니다. 이는 인터프리터가 객체를 절대로 공유하지 않는다는 의미입니다(불멸의 변경 불가능한 내장 객체가 사용되는 매우 특정한 경우는 제외합니다). 각 인터프리터에는 자체 모듈(sys.modules), 클래스, 함수 및 변수가 있습니다. 두 인터프리터가 동일한 클래스를 정의하는 경우에도 각각 자체 복사본을 갖습니다. C의 상태에도 동일하게 적용되며, 여기에는 확장 모듈의 상태도 포함됩니다. CPython C API 문서에서 explain more 자세히 설명합니다.

특히 인터프리터가 항상 공유하는 프로세스 전역 상태가 있으며, 일부는 변경 가능하고 일부는 변경 불가능합니다. 변경 불가능한 상태를 공유하면 문제가 거의 발생하지 않으면서 몇 가지 이점(주로 성능)을 제공합니다. 그러나 공유되는 모든 변경 가능한 상태에는 특별한 관리가 필요하며, 특히 스레드 안전성을 위해 필요한 관리 중 일부는 OS가 대신 처리합니다.

변경 가능:

• 파일 디스크립터
• 저수준 환경 변수
• 프로세스 메모리(단, 할당자는 격리되어 있습니다)
• 인터프리터 목록

변경 불가능:

• 내장 타입(예: dict, bytes)
• 싱글턴(예: None)
• 내장/확장/동결 모듈의 기본 정적 모듈 데이터(예: 함수)

기존 실행 구성 요소

서브인터프리터에서 코드가 실행되는 방식을 이해하는 데 도움이 될 수 있는 Python의 기존 구성 요소가 여러 가지 있습니다.

CPython에서 각 구성 요소는 다음 C API 함수 중 하나(또는 변형)를 중심으로 구성됩니다.

• PyEval_EvalCode(): 주어진 코드 객체로 바이트코드 인터프리터를 실행합니다.
• PyRun_String(): 컴파일 + PyEval_EvalCode()를 수행합니다.
• PyRun_File(): 읽기 + 컴파일 + PyEval_EvalCode()를 수행합니다.
• PyRun_InteractiveOneObject(): 컴파일 + PyEval_EvalCode()
• PyObject_Call(): PyEval_EvalCode()를 호출합니다.

builtins.exec()

내장 exec()를 사용하여 Python 코드를 실행할 수 있습니다. 이는 본질적으로 C API 함수 PyRun_String()와 PyEval_EvalCode()를 둘러싼 래퍼입니다.

다음은 내장 exec()의 관련 특성입니다:

• 현재 OS 스레드에서 실행되며, 그곳에서 실행 중이던 모든 작업을 일시 중지하고, exec()가 완료되면 재개합니다. 다른 OS 스레드에는 영향을 주지 않습니다. (현재 Python 스레드를 일시 중지하지 않으려면 threading.Thread에서 exec()를 실행하십시오.)
• 추가 스레드를 시작할 수 있으며, 해당 스레드는 이를 중단하지 않습니다.
• 이는 “globals” 네임스페이스(그리고 “locals” 네임스페이스)에 대해 실행됩니다. 모듈 수준에서 exec()는 현재 모듈의 __dict__를 사용하도록 기본 설정됩니다(즉, globals()를 사용합니다). exec()는 해당 네임스페이스를 있는 그대로 사용하며, 실행 전이나 후에 이를 비우지 않습니다.
• 실행한 코드에서 포착되지 않은 예외를 전파합니다. 예외는 원래 exec()를 호출한 Python 스레드의 exec()호출에서 발생합니다.

명령줄

python CLI는 Python 코드를 실행하는 여러 방법을 제공합니다. 각 경우에 해당하는 C API 호출로 매핑됩니다:

• <no args>, -i - REPL을 실행합니다(PyRun_InteractiveOneObject()).
• <filename> - 스크립트를 실행합니다(PyRun_File()).
• -c <code> - 주어진 Python 코드를 실행합니다(PyRun_String()).
• -m module - 모듈을 스크립트로 실행합니다(runpy._run_module_as_main()을 통한 PyEval_EvalCode()).

각 경우에 이는 본질적으로 주 인터프리터의 __main__ 모듈 최상위 수준에서 exec()를 실행하는 변형입니다.

threading.Thread

Python 스레드가 시작되면 새 스레드 상태를 사용하여 PyObject_Call()로 “target” 함수를 실행합니다. globals 네임스페이스는 func.__globals__에서 가져오며, 포착되지 않은 예외는 버려집니다.

동기

interpreters 모듈은 다중 인터프리터 기능에 대한 고수준 인터페이스를 제공합니다. 목표는 CPython의 기존 다중 인터프리터 기능을 Python 코드에서 더 쉽게 사용할 수 있도록 만드는 것입니다. CPython에 인터프리터별 GIL (PEP 684)가 있고 사람들이 다중 인터프리터 사용에 더 큰 관심을 보이는 현재 특히 관련성이 높습니다.

표준 라이브러리 모듈이 없으면 사용자는 C API에 제한되며, 이로 인해 다중 인터프리터를 시험하고 활용할 수 있는 범위가 제한됩니다.

이 모듈에는 인터프리터 간 통신을 위한 기본 메커니즘이 포함됩니다. 그러한 메커니즘이 없으면 다중 인터프리터는 훨씬 덜 유용한 기능입니다.

사양

이 모듈은 다음을 수행합니다:

• 기존의 다중 인터프리터 지원을 공개합니다
• 인터프리터 간 통신을 위한 기본 메커니즘을 도입합니다

이 모듈은 새로운 저수준 _interpreters 모듈을 래핑합니다(threading 모듈과 동일한 방식입니다). 그러나 해당 저수준 API는 공개적으로 사용하도록 설계되지 않았으므로 이 제안의 일부가 아닙니다.

인터프리터 사용

이 모듈은 다음 함수를 정의합니다:

• get_current() -> Interpreter

  현재 실행 중인 인터프리터에 해당하는 Interpreter 객체를 반환합니다.

• list_all() -> list[Interpreter]

  현재 어떤 OS 스레드에서 실행 중인지 여부와 관계없이, 존재하는 각 인터프리터에 해당하는 Interpreter 객체를 반환합니다.

• create() -> Interpreter

  새 인터프리터를 생성하고 해당 인터프리터의 Interpreter 객체를 반환하십시오. 인터프리터는 스스로 어떤 작업도 수행하지 않으며 어떤 OS 스레드에도 본질적으로 연결되지 않습니다. 그러한 연결은 인터프리터에서 실제로 무언가가 실행될 때(예: Interpreter.exec()) 그리고 실행 중인 동안에만 발생합니다. 인터프리터에 사용할 준비가 된 스레드 상태가 있을 수도 있고 없을 수도 있지만, 이는 전적으로 내부 구현 세부 사항입니다.

인터프리터 객체

해당 고유 ID를 가진 인터프리터(PyInterpreterState)를 나타내는 interpreters.Interpreter 객체입니다. 주어진 인터프리터마다 객체는 하나만 존재합니다.

인터프리터가 interpreters.create()로 생성된 경우, 해당 ID를 가진 모든 Interpreter 객체가(모든 인터프리터에 걸쳐) 삭제되는 즉시 소멸됩니다.

Interpreter 객체는 interpreters.create()로 생성된 인터프리터 외의 다른 인터프리터를 나타낼 수도 있습니다. 예를 들어 Python 런타임 초기화로 생성된 주 인터프리터와 C-API를 통해 Py_NewInterpreter()를 사용하여 생성된 인터프리터가 있습니다. 이러한 Interpreter 객체는 해당 인터프리터와 상호 작용할 수 없습니다. 예를 들어 Interpreter.exec()을 사용할 수 없습니다(향후에는 이 제한을 완화할 수도 있습니다).

속성 및 메서드:

• id

  (읽기 전용) 이 Interpreter 인스턴스가 나타내는 인터프리터를 식별하는 음이 아닌 int 값입니다. 개념적으로 이는 프로세스 ID와 유사합니다.

• __hash__()

  인터프리터의 id의 해시를 반환합니다. 이는 ID의 정수 값에 대한 해시와 동일합니다.

• is_running() -> bool

  인터프리터가 현재 해당 인터프리터의 __main__ 모듈에서 코드를 실행 중이면 True를 반환합니다. 하위 스레드는 제외합니다.

  인터프리터의 __main__ 모듈에서 스크립트(코드)를 실행 중인 운영 체제 스레드가 있는 경우만을 의미합니다. 기본적으로 일부 운영 체제 스레드에서 Interpreter.exec()가 실행 중인지 여부를 의미합니다. 하위 스레드에서 실행 중인 코드는 무시합니다.

• prepare_main(**kwargs)

  인터프리터의 __main__ 모듈에 하나 이상의 객체를 바인딩합니다.

  키워드 인자 이름이 특성 이름으로 사용됩니다. 대부분의 객체는 인터프리터에서 복사본이 바인딩되며, 그 사이에 pickle이 사용됩니다. memoryview와 같은 일부 객체의 경우 인터프리터 간에 기반 데이터가 공유됩니다. Shareable Objects를 참조하십시오.

  prepare_main()은 인터프리터에서 코드를 실행하기 전에 해당 인터프리터의 전역 변수를 초기화하는 데 유용합니다.

• exec(code, /)

  해당 __main__ 모듈을 사용하여 인터프리터에서(현재 운영 체제 스레드에서) 주어진 소스 코드를 실행합니다. 아무것도 반환하지 않습니다.

  이는 현재 운영 체제 스레드에서 이 인터프리터로 전환한 다음, 이 인터프리터의 __main__ 모듈의 __dict__를 전역 및 지역 변수로 사용하여 내장 exec()를 호출하는 것과 본질적으로 동일합니다.

  현재 운영 체제 스레드에서 실행 중인 코드(다른 인터프리터의 코드)는 Interpreter.exec()가 완료될 때까지 사실상 일시 중지됩니다. 이를 일시 중지하지 않으려면 새 threading.Thread를 생성하고 그 안에서 Interpreter.exec()를 호출하십시오(Interpreter.call_in_thread()가 수행하는 방식과 같습니다).

  Interpreter.exec()는 실행 전이나 후에 인터프리터의 상태나 __main__ 모듈을 재설정하지 않으므로, 이후 호출할 때마다 이전 호출이 중단된 지점부터 계속 실행됩니다. 이는 나중에 일부 반복 작업을 수행하기 전에 인터프리터를 초기화하는 코드(예: import를 사용하는 코드)를 실행하는 데 유용할 수 있습니다.

  포착되지 않은 예외가 발생하면 해당 예외는 ExecutionFailed로 호출한 인터프리터에 전파됩니다. 호출된 인터프리터를 기준으로 생성된 원래 예외의 전체 오류 표시가 전파된 ExecutionFailed에 보존됩니다. 여기에는 구문 오류 세부 정보와 연쇄 예외 같은 모든 추가 정보가 포함된 전체 트레이스백이 포함됩니다. ExecutionFailed가 포착되지 않으면 전체 오류 표시가 표시되며, 이는 전파된 예외가 주 인터프리터에서 발생하여 포착되지 않은 경우와 거의 같습니다. 전체 트레이스백은 디버깅할 때 특히 유용합니다.

  예외 전파를 원하지 않는다면 Interpreter.exec()에 전달된 code를 둘러싸고 명시적인 try-except를 사용해야 합니다. 마찬가지로 예외의 특정 정보에 의존하는 모든 오류 처리는 주어진 code를 둘러싸고 명시적인 try-except를 사용해야 합니다. ExecutionFailed는 해당 정보를 보존하지 않기 때문입니다.

• call(callable, /)

  인터프리터에서 호출 가능 객체를 호출합니다. 반환 값은 폐기됩니다. 호출 가능 객체가 예외를 발생시키면 Interpreter.exec()와 동일한 방식으로 ExecutionFailed예외로 전파됩니다.

  현재는 인자를 받지 않고 셀 변수가 없는 일반 함수만 지원합니다. 자유 전역 변수는 대상 인터프리터의 __main__ 모듈을 기준으로 확인합니다.

  향후에는 적어도 부분적으로 pickle을 통해 인자, 클로저 및 더 다양한 호출 가능 객체를 지원할 수 있습니다. 반환 값을 버리지 않는 방안도 고려할 수 있습니다. 이러한 초기 제한은 모듈의 기본 기능을 더 빠르게 사용자에게 제공하기 위해 마련되었습니다.

• call_in_thread(callable, /) -> threading.Thread

  기본적으로 새 스레드에서 Interpreter.call()을 적용합니다. 반환 값은 버리며 예외는 전파하지 않습니다.

  call_in_thread()은 대략 다음과 동등합니다.:

  def task():
      interp.call(func)
  t = threading.Thread(target=task)
  t.start()
  

• close()

  기반 인터프리터를 제거합니다.

인터프리터 간 통신

이 모듈은 특수 큐를 통한 기본 통신 메커니즘을 도입합니다.

interpreters.Queue 객체가 있지만, 이는 실제 데이터 구조, 즉 어떤 한 인터프리터의 외부에 존재하는 무제한 FIFO 큐를 프록시할 뿐입니다. 이러한 큐에는 인터프리터 격리를 위반하지 않고 인터프리터 간에 객체 데이터를 안전하게 전달하기 위한 특별한 처리가 마련되어 있습니다. 여기에는 스레드 안전성도 포함됩니다.

Python의 다른 큐와 마찬가지로, 각 “put”에서는 객체가 뒤에 추가되고 각 “get”에서는 앞에서 다음 객체가 꺼내집니다. 추가된 모든 객체는 삽입된 순서대로 꺼내집니다.

피클할 수 있는 모든 객체는 interpreters.Queue를 통해 전송할 수 있습니다.

실제 객체가 전송되는 것이 아니라 그 기반 데이터가 전송된다는 점에 유의하십시오. 결과 객체는 원본과 엄밀하게 동등합니다. 대부분의 객체에서는 기반 데이터가 직렬화됩니다(예: 피클됨). memoryview와 같은 일부 경우에는 직렬화하지 않고 기반 데이터가 전송되며 공유됩니다. Shareable Objects 를 참조하십시오.

이 모듈은 다음 함수를 정의합니다.

• create_queue(maxsize=0) -> Queue

  새 큐를 생성합니다. maxsize가 0 이하이면 큐는 무제한입니다.

큐 객체

interpreters.Queue 객체는 interpreters 모듈이 노출하는 인터프리터 간 안전한 기반 큐의 프록시로 작동합니다. 각 Queue 객체는 해당하는 고유 ID를 가진 큐를 나타냅니다. 주어진 큐마다 객체는 하나만 존재합니다.

Queue는 queue.Queue의 모든 메서드를 구현하지만 task_done()과 join()은 제외하므로, asyncio.Queue및 multiprocessing.Queue와 유사합니다.

속성 및 메서드:

• id

  (읽기 전용) 해당 인터프리터 간 큐를 식별하는 음이 아닌 int입니다. 개념적으로 이는 파이프에 사용되는 파일 디스크립터와 유사합니다.

• maxsize

  (읽기 전용) 큐에 허용되는 항목의 수입니다. 0은 “무제한”을 의미합니다.

• __hash__()

  큐의 id에 대한 해시를 반환합니다. 이는 ID의 정수 값에 대한 해시와 같습니다.

• empty()

  큐가 비어 있으면 True를, 그렇지 않으면 False를 반환합니다.

  이는 호출 시점의 상태에 대한 스냅샷일 뿐입니다. 다른 스레드나 인터프리터로 인해 상태가 변경될 수 있습니다.

• full()

  큐에 maxsize개의 항목이 있으면 True를 반환합니다.

  큐가 maxsize=0(기본값)으로 초기화된 경우 full()은 절대 True를 반환하지 않습니다.

  이는 호출 시점의 상태에 대한 스냅샷일 뿐입니다. 다른 스레드나 인터프리터로 인해 상태가 변경될 수 있습니다.

• qsize()

  항목의 수를 반환합니다.

  이는 호출 시점의 상태에 대한 스냅샷일 뿐입니다. 다른 스레드나 인터프리터로 인해 상태가 변경될 수 있습니다.

• put(obj, timeout=None)

  객체를 큐에 추가합니다.

  maxsize > 0이고 큐가 가득 찬 경우, 사용 가능한 슬롯이 생길 때까지 차단됩니다. timeout이 양수이면 해당 초 수 이상 차단한 다음 interpreters.QueueFull을 발생시킵니다. 그렇지 않으면 영원히 차단됩니다.

  거의 모든 객체를 큐를 통해 보낼 수 있습니다. memoryview와 같은 일부 경우에는 단순히 복사되는 것이 아니라 기본 데이터가 실제로 공유됩니다. Shareable Objects 를 참조하십시오.

  객체가 여전히 큐에 있고, 해당 객체를 큐에 넣은(즉, 객체가 속한) 인터프리터가 소멸되면 객체는 큐에서 즉시 제거됩니다. (나중에 제거된 객체를 센티널로 대체하거나 해당 get()호출에 대해 예외를 발생시키는 옵션을 추가할 수도 있습니다.)

• put_nowait(obj

  put()과 같지만 사실상 즉시 타임아웃이 적용됩니다. 따라서 큐가 가득 차 있으면 interpreters.QueueFull을 즉시 발생시킵니다.

• get(timeout=None) -> object

  큐에서 다음 객체를 꺼내 반환합니다. 큐가 비어 있는 동안 블록합니다. 양의 timeout이 제공되고 해당 시간(초) 동안 객체가 큐에 추가되지 않으면 interpreters.QueueEmpty를 발생시킵니다.

• get_nowait() -> object

  get()과 같지만 블록하지 않습니다. 큐가 비어 있지 않으면 다음 항목을 반환합니다. 그렇지 않으면 interpreters.QueueEmpty를 발생시킵니다.

공유 가능한 객체

“공유 가능한” 객체는 한 인터프리터에서 다른 인터프리터로 전달할 수 있는 객체입니다. 객체가 인터프리터 간에 실제로 직접 공유되는 것은 아닙니다. 그러나 공유 객체는 변경 가능성에 대한 주의 사항을 고려하여 마치직접 공유되는 것처럼 취급해야 합니다.

피클링할 수 있는 모든 객체는 공유 가능합니다. 따라서 거의 모든 객체가 공유 가능합니다. interpreters.Queue 객체도 공유 가능합니다.

객체를 interp.prepare_main()또는 queue.put()을 사용하여 인터프리터로 보내는 거의 모든 경우에 실제 객체가 전송되는 것은 아닙니다. 대신 객체의 기반 데이터가 전송됩니다. 대부분의 객체는 피클링되고, 수신 인터프리터가 이를 언피클링합니다.

주목할 만한 예외는 memoryview와 같이 “buffer” 프로토콜을 구현하는 객체입니다. 해당 객체의 기반이 되는 Py_buffer는 인터프리터 간에 실제로 공유됩니다. interp.prepare_main()과 queue.get()은 버퍼를 새로운 memoryview객체로 감쌉니다.

대부분의 변경 가능한 객체는 다른 인터프리터로 전송될 때 복사됩니다. 따라서 원본이나 복사본에 대한 변경 사항은 다른 쪽에 절대 동기화되지 않습니다. 피클링을 통해 공유되는 변경 가능한 객체가 이 범주에 속합니다. 그러나 interpreters.Queue와 버퍼 프로토콜을 구현하는 객체는 기반 데이터가 인터프리터 간에 실제로 공유된 상태이므로 객체가 동기화된 상태로 유지되는 주목할 만한 경우입니다.

인터프리터가 변경 가능한 데이터를 실제로 공유하면 데이터 경쟁의 위험이 항상 존재합니다. 스레드 안전성을 포함한 인터프리터 간 안전성은 interpreters.Queue의 핵심 기능입니다.

그러나 버퍼 프로토콜(즉, Py_buffer)에는 데이터 경쟁을 방지하기 위한 네이티브 수단이 없습니다. 대신 안전성을 나타내기 위해 큐를 통해 토큰을 앞뒤로 전달하든(Synchronization 참조), 개별 인터프리터에 하위 범위 독점권을 할당하든, 스레드 안전성 관리는 사용자의 책임입니다.

대부분의 객체는 큐(interpreters.Queue)를 통해 공유됩니다. 인터프리터들이 서로 간에 정보를 통신하기 때문입니다. 객체는 더 드물게 prepare_main()을 통해 공유되며, 이는 인터프리터에서 코드를 실행하기 전에 인터프리터를 설정하는 데 사용됩니다. 그러나 다른 인터프리터에 추가 통신 수단을 제공하기 위해 큐를 공유하는 주요 방법은 prepare_main()입니다.

동기화

두 인터프리터를 동기화해야 하는 상황이 있습니다. 여기에는 리소스 공유, 작업자 관리 또는 순차적 일관성 유지가 포함될 수 있습니다.

스레드 프로그래밍에서 일반적인 동기화 기본 요소는 뮤텍스와 같은 유형입니다. threading 모듈은 이러한 기본 요소를 여러 개 제공합니다. 그러나 인터프리터는 객체를 공유할 수 없으므로 threading.Lock 객체도 공유할 수 없습니다.

interpreters 모듈은 이러한 전용 동기화 기본 요소를 제공하지 않습니다. 대신 interpreters.Queue 객체가 필요한 모든 기능을 제공합니다.

예를 들어 관리되는 액세스가 필요한 공유 리소스가 있다면 큐를 사용하여 이를 관리할 수 있으며, 인터프리터들은 누가 해당 리소스를 사용할 수 있는지 나타내기 위해 객체를 주고받습니다:

import interpreters
from mymodule import load_big_data, check_data

numworkers = 10
control = interpreters.create_queue()
data = memoryview(load_big_data())

def worker():
    interp = interpreters.create()
    interp.prepare_main(control=control, data=data)
    interp.exec("""if True:
        from mymodule import edit_data
        while True:
            token = control.get()
            edit_data(data)
            control.put(token)
        """)
threads = [threading.Thread(target=worker) for _ in range(numworkers)]
for t in threads:
    t.start()

token = 'football'
control.put(token)
while True:
    control.get()
    if not check_data(data):
        break
    control.put(token)

예외

• InterpreterError

  일부 인터프리터 관련 오류가 발생했음을 나타냅니다.

  이 예외는 Exception의 서브클래스입니다.

• InterpreterNotFoundError

  기반 인터프리터가 소멸된 후 Interpreter 메서드에서 발생하며, C-API를 통한 경우 등이 이에 해당합니다.

  이 예외는 InterpreterError의 서브클래스입니다.

• ExecutionFailed

  처리되지 않은 예외가 발생하면 Interpreter.exec() 및 Interpreter.call()에서 발생합니다. 이 예외의 오류 표시에는 처리되지 않은 예외의 트레이스백이 포함되며, 일반 오류 표시 뒤에 표시됩니다. 이는 ExceptionGroup에서 발생하는 방식과 유사합니다.

  속성:

  • type - 원래 예외 클래스의 표현이며, __name__, __module__ 및 __qualname__ 속성을 포함합니다.
  • msg - 원래 예외의 str(exc)
  • snapshot - 원래 예외에 대한 traceback.TracebackException 객체

  이 예외는 InterpreterError의 서브클래스입니다.

• QueueError

  일부 큐 관련 오류가 발생했음을 나타냅니다.

  이 예외는 Exception의 서브클래스입니다.

• QueueNotFoundError

  기반 큐가 소멸된 후 interpreters.Queue 메서드에서 발생합니다.

  이 예외는 QueueError의 서브클래스입니다.

• QueueEmpty

  큐가 비어 있을 때 기본값 없이 Queue.get()(또는 get_nowait())에서 발생합니다.

  이 예외는 QueueError와 표준 라이브러리 queue.Empty모두의 서브클래스입니다.

• QueueFull

  큐가 이미 최대 크기에 도달했을 때(타임아웃과 함께) Queue.put()또는 put_nowait()에서 발생합니다.

  이 예외는 QueueError와 표준 라이브러리 queue.Empty모두의 서브클래스입니다.

InterpreterPoolExecutor

새로운 interpreters 모듈과 함께 새로운 concurrent.futures.InterpreterPoolExecutor가 제공됩니다. 이는 ThreadPoolExecutor의 파생 클래스로, 각 작업자는 자체 스레드에서 실행되지만 각 작업자마다 자체 서브인터프리터가 있습니다.

다른 실행기와 마찬가지로 InterpreterPoolExecutor는 작업과 초기화 함수에 호출 가능 객체를 지원합니다. 또한 다른 실행기와 마찬가지로 두 경우의 인자는 대부분 제한되지 않습니다. 호출 가능 객체와 인자는 작업자의 인터프리터로 전송될 때 일반적으로 직렬화되며, ProcessPoolExecutor가 작동하는 방식처럼 pickle 등을 사용합니다. 이는 (적어도 초기에는) 훨씬 더 제한적인 Interpreter.call()과 대조됩니다.

작업자 간 또는 실행기(일반적으로 실행기의 인터프리터)와 작업자 간의 통신은 초기화 함수로 설정한 interpreters.Queue객체를 통해 계속 수행할 수 있습니다.

sys.implementation.supports_isolated_interpreters

Python 구현은 서브인터프리터를 지원할 필요가 없지만, 대부분의 주요 구현은 지원합니다. 구현이 서브인터프리터를 지원하면 sys.implementation.supports_isolated_interpreters는 True로 설정됩니다. 그렇지 않으면 False가 됩니다. 이 기능이 지원되지 않으면 interpreters 모듈을 가져올 때 ImportError가 발생합니다.

예제

다음 예제는 여러 인터프리터가 유용할 수 있는 실제 사례를 보여 줍니다.

예제 1:

하위 스레드의 작업자를 통해 처리될 요청 스트림이 들어옵니다.

• 각 작업자 스레드에는 자체 인터프리터가 있습니다.
• 작업자에게 작업을 보내는 큐 하나와 결과를 반환하는 또 다른 큐 하나가 있습니다.
• 결과는 전용 스레드에서 처리됩니다.
• 각 작업자는 “stop” 센티널(None)을 받을 때까지 계속 실행됩니다.
• 결과 처리기는 모든 작업자가 중지할 때까지 계속 실행됩니다.

import interpreters
from mymodule import iter_requests, handle_result

tasks = interpreters.create_queue()
results = interpreters.create_queue()

numworkers = 20
threads = []

def results_handler():
    running = numworkers
    while running:
        try:
            res = results.get(timeout=0.1)
        except interpreters.QueueEmpty:
            # No workers have finished a request since last time.
            pass
        else:
            if res is None:
                # A worker has stopped.
                running -= 1
            else:
                handle_result(res)
    empty = object()
    assert results.get_nowait(empty) is empty
threads.append(threading.Thread(target=results_handler))

def worker():
    interp = interpreters.create()
    interp.prepare_main(tasks=tasks, results=results)
    interp.exec("""if True:
        from mymodule import handle_request, capture_exception

        while True:
            req = tasks.get()
            if req is None:
                # Stop!
                break
            try:
                res = handle_request(req)
            except Exception as exc:
                res = capture_exception(exc)
            results.put(res)
        # Notify the results handler.
        results.put(None)
        """)
threads.extend(threading.Thread(target=worker) for _ in range(numworkers))

for t in threads:
    t.start()

for req in iter_requests():
    tasks.put(req)
# Send the "stop" signal.
for _ in range(numworkers):
    tasks.put(None)

for t in threads:
    t.join()

예제 2:

이 경우는 하위 스레드에 작업자가 많이 있다는 점에서 앞선 경우와 유사합니다. 그러나 이번에는 코드가 대규모 데이터 배열을 여러 청크로 나누며, 각 작업자가 한 번에 하나의 청크를 처리합니다. 해당 데이터를 각 인터프리터에 복사하는 것은 매우 비효율적이므로, 코드는 memoryview 버퍼를 직접 공유하는 방식을 활용합니다.

• 모든 인터프리터가 원본 배열의 버퍼를 공유합니다.
• 각 인터프리터는 결과를 두 번째 공유 버퍼에 기록합니다.
• 작업을 작업자에게 보내기 위해 큐를 사용합니다.
• 주어진 원본 배열 인덱스를 읽는 작업자는 언제나 하나뿐입니다.
• 주어진 결과 인덱스에 기록하는 작업자는 언제나 하나뿐입니다(이 방식으로 스레드 안전성을 보장합니다).

import interpreters
import queue
from mymodule import read_large_data_set, use_results

numworkers = 3
data, chunksize = read_large_data_set()
buf = memoryview(data)
numchunks = (len(buf) + 1) / chunksize
results = memoryview(b'\0' * numchunks)

tasks = interpreters.create_queue()

def worker(id):
    interp = interpreters.create()
    interp.prepare_main(data=buf, results=results, tasks=tasks)
    interp.exec("""if True:
        from mymodule import reduce_chunk

        while True:
            req = tasks.get()
            if res is None:
                # Stop!
                break
            resindex, start, end = req
            chunk = data[start: end]
            res = reduce_chunk(chunk)
            results[resindex] = res
        """)
threads = [threading.Thread(target=worker) for _ in range(numworkers)]
for t in threads:
    t.start()

for i in range(numchunks):
    # Assume there's at least one worker running still.
    start = i * chunksize
    end = start + chunksize
    if end > len(buf):
        end = len(buf)
    tasks.put((start, end, i))
# Send the "stop" signal.
for _ in range(numworkers):
    tasks.put(None)

for t in threads:
    t.join()

use_results(results)

근거

최소 API

핵심 개발 팀은 사용자가 Python 코드에서 여러 인터프리터를 어떻게 사용할지에 대한 실제 경험이 없으므로, 이 제안에서는 초기 API를 가능한 한 간결하고 최소한으로 유지합니다. 목표는 필요에 따라 이후에 더 발전된 기능을 추가할 수 있는 충분히 검토된 기반을 제공하는 것입니다.

그렇지만 제안된 설계에는 커뮤니티에서 서브인터프리터를 기존에 사용하면서 얻은 교훈, 기존 표준 라이브러리 모듈에서 얻은 교훈, 그리고 다른 프로그래밍 언어에서 얻은 교훈이 반영되어 있습니다. 또한 CPython 테스트 스위트에서 서브인터프리터를 사용한 경험과 concurrency benchmarks를 사용한 경험도 고려했습니다.

create(), create_queue()

일반적으로 사용자는 타입을 호출하여 해당 타입의 인스턴스를 생성하며, 그러면 객체의 리소스가 할당됩니다. interpreters 모듈은 이와 다른 접근 방식을 취하므로, 사용자는 새 인터프리터를 얻으려면 create()를 호출하고 새 큐를 얻으려면 create_queue()를 호출해야 합니다. interpreters.Interpreter()를 직접 호출하면 기존 인터프리터를 감싸는 래퍼만 반환됩니다(interpreters.Queue()도 마찬가지입니다).

이는 인터프리터와 큐가 특수한 리소스이기 때문입니다. 이러한 리소스는 프로세스 전역에 존재하며 현재 인터프리터가 관리하거나 소유하지 않습니다. 따라서 interpreters 모듈에서는 인터프리터(또는 큐)를 생성하는 작업과 interpreters.Interpreter(또는 interpreters.Queue)의 인스턴스를 생성하는 작업을 명확히 구분합니다.

인터프리터.prepare_main()은 여러 변수를 설정합니다.

prepare_main()은 일종의 설정자 함수로 볼 수 있습니다. 대부분의 설정자가 한 번에 하나의 항목을 설정하는 것과 달리, 한 번에 여러 이름을 설정할 수 있습니다. 예를 들어 interp.prepare_main(spam=1, eggs=2)와 같습니다. 주된 이유는 효율성입니다.

인터프리터의 __main__.__dict__에 값을 설정하려면 구현에서 먼저 OS 스레드를 식별된 인터프리터로 전환해야 하며, 여기에는 무시할 수 없는 오버헤드가 발생합니다. 값을 설정한 후에는 다시 전환해야 합니다. 또한 인터프리터 간에 객체를 전달하는 메커니즘에도 추가 오버헤드가 있으며, 여러 값을 한 번에 설정하면 이를 전체적으로 줄일 수 있습니다.

따라서 prepare_main()은 한 번에 여러 값을 설정할 수 있도록 지원합니다.

예외 전파

Interpreter.exec()를 통해 서브인터프리터에서 발생한 처리되지 않은 예외는 threading.Thread()처럼 사실상 무시되거나, 내장 exec()처럼 전파될 수 있습니다. Interpreter.exec()은 내장 exec()와 마찬가지로 동기 작업이므로 처리되지 않은 예외는 전파됩니다.

그러나 이러한 예외는 직접 발생하지 않습니다. 이는 인터프리터가 서로 격리되어 있으며 예외를 포함한 객체를 공유해서는 안 되기 때문입니다. 요약본, 복사본 또는 예외를 감싸는 프록시와 같은 예외의 대체물을 발생시키면 이 문제를 해결할 수 있습니다. 이러한 대체물은 무엇이든 디버깅에 유용한 트레이스백을 보존할 수 있습니다. 발생하는 ExecutionFailed는 이러한 대체물입니다.

고려해야 할 또 다른 문제가 있습니다. 전파된 예외가 즉시 포착되지 않으면 호출 스택을 따라 올라가 포착될 때까지(또는 포착되지 않을 때까지) 전파됩니다. 다른 곳의 코드가 해당 예외를 포착할 수 있는 경우, 예외가 현재 인터프리터가 아니라 서브인터프리터(즉, “원격” 소스)에서 발생했음을 식별하는 것이 유용합니다. 그렇기 때문에 Interpreter.exec()는 ExecutionFailed를 발생시키며, 원래 예외와 일치하는 클래스를 가진 복사본이나 프록시가 아니라 일반적인 Exception입니다. 예를 들어, 서브인터프리터에서 발생한 포착되지 않은 ValueError는 이후의 try: ... except ValueError: ...에서 절대 포착되지 않습니다. 대신 ExecutionFailed를 직접 처리해야 합니다.

반면 Interpreter.call()에서 전파된 예외는 ExecutionFailed를 사용하지 않고 직접 발생하며, 호출하는 인터프리터에서 발생한 것처럼 동작합니다. 이는 Interpreter.call()이 인터프리터 사이에서 일반적으로 전달할 수 없는 객체를 지원하기 위해 pickle을 사용하는 상위 수준 메서드이기 때문입니다.

객체와 ID 프록시

인터프리터와 큐 모두에서 저수준 모듈은 해당 프로세스 전역 ID를 통해 기반 상태를 노출하는 프록시 객체를 사용합니다. 두 경우 모두 상태는 마찬가지로 프로세스 전역이며 여러 인터프리터에서 사용됩니다. 따라서 이들은 PyObject로 구현하기에 적합하지 않으며, 이러한 구현은 인터프리터별 데이터에 대해서만 실질적으로 선택 가능한 방법입니다. 그렇기 때문에 interpreters 모듈은 대신 ID를 통해 약하게 연결된 객체를 제공합니다.

거부된 아이디어

자세한 내용은 PEP 554를 참조하십시오.

Copyright

This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.