Python 제너레이터는 호출 사이에 실행 상태를 유지하는 중단된 프레임 객체(PyFrameObject)로 구현됩니다. send(value)가 호출되면 CPython의 내부 gen_send_ex() 함수가 이 값을 제너레이터의 값 스택에 푸시하고, 이후 yield 표현이 이를 팝하여 호출자에게 반환합니다. 이는 초기 next() 호출과는 다릅니다. next() 호출은 제너레이터를 초기 상태(f_lasti == -1)에서 첫 번째 yield 표현으로 준비하기 위해 묵시적으로 None을 보냅니다. 첫 번째로 제너레이터가 yield 할 때까지 send()가 비-None 값을 사용하면, 제너레이터 프레임에 값을 받을 스택 위치가 없기 때문에 CPython은 TypeError를 발생시킵니다. 이 구조적 구별은 제너레이터가 첫 번째 중단 지점에 도달한 후에만 양방향 통신이 시작되도록 보장합니다.
우리는 하이퍼-빈도 시장 데이터 피드를 처리하기 위해 역압력 인식 데이터 파이프라인을 구현해야 했습니다. 이 파이프라인에서는 하류 소비자가 상류 생산자에게 데이터 흐름을 조절하거나 재개하도록 동적으로 신호를 보낼 수 있어야 했으며, 메시지를 버리거나 메모리를 소모하지 않는 것이 중요했습니다.
고려된 하나의 접근 방식은 파이프라인 단계 간에 경계가 있는 threading과 queue.Queue 인스턴스를 사용하는 것이었습니다. 이는 익숙한 블로킹 의미론과 스레드 안전성을 제공했지만, 심각한 GIL 경쟁 및 컨텍스트 전환 오버헤드로 인해 하이 처리량에서 15% CPU를 소비하며 예측할 수 없는 지연 스파이크를 초래했습니다.
또 다른 대안은 asyncio 코루틴 및 async/await 구문으로 이주하는 것이었습니다. 이는 GIL 경쟁을 제거할 수 있었지만, 우리의 동기 수치 분석 라이브러리를 비동기 호환 형태로 완전히 다시 써야 했으며, 이는 수천 줄의 비즈니스 로직에 영향을 미치고 레거시 C 확장과의 호환성 문제를 일으키는 전염성 리팩토링을 발생시켰습니다.
우리는 결국 send()를 사용하여 "수요 크레딧"을 상류로 전송하는 제너레이터 기반 협력 멀티태스킹 접근 방식을 선택했습니다. 이 솔루션은 GIL 오버헤드를 완전히 피할 수 있었고, 제너레이터가 동기 코드에서 작동하기 때문에 라이브러리 재작성이 필요 없으며, demand = (yield data_chunk) 패턴을 통해서 하류 소비자가 상류 생산을 즉시 중단할 수 있도록 0 값을 보낼 수 있었습니다.
결과적으로 메모리 사용량이 큐 접근 방식에 비해 40% 감소하고, 지연이 5 밀리초 이하로 안정되었으며, 코드베이스는 명시적 yield 포인트로 중단 경계를 표시하여 가독성을 유지했습니다.
비-None 값을 갖는 send()를 방금 생성된 제너레이터에서 호출하면 왜 TypeError가 발생하며, 이 제약이 제너레이터 프로토콜을 어떻게 강화합니까?
제너레이터가 처음 생성될 때, 그 프레임 포인터 f_lasti는 -1로 설정되며, 이는 바이트코드가 실행되지 않았음을 나타냅니다. CPython 인터프리터는 send()가 호출될 때 제너레이터가 시작되지 않았는지 확인합니다; 만약 보낸 값이 None이 아니면, yield 표현에 도달하지 않았기 때문에 스택 슬롯을 제공할 수 없어 TypeError가 발생합니다. 이 강제 시행은 제너레이터 초기화 로직이 완료된 후에만 양방향 통신이 시작되도록 보장하여, 값이 오직 명시적 yield 중단 지점에서 제너레이터로 흘러 들어가도록 보장합니다.
어떻게 generator.close()가 제너레이터 내에서 정리 코드를 실행하도록 보장하며, GeneratorExit 예외가 일반 예외와 어떻게 구별됩니까?
close() 메서드는 현재 중단 지점에서 제너레이터로 GeneratorExit 예외를 보냅니다. GeneratorExit는 잘못된 처리를 방지하기 위해 Exception이 아닌 BaseException에서 상속받습니다. 제너레이터가 GeneratorExit를 잡고 다시 발생시키거나 정상적으로 종료하면, close()는 조용히 반환됩니다. 그러나 제너레이터가 GeneratorExit에 대한 응답으로 값을 생성하면, CPython은 종료된 제너레이터가 새 값을 생성해서는 안 되기 때문에 RuntimeError를 발생시킵니다. 이 메커니즘은 제너레이터 본문 내의 finally 블록과 컨텍스트 관리자가 강제 종료 중에도 실행되도록 보장합니다.
어떤 메커니즘이 yield from을 통해 중첩된 제너레이터 간에 보낸 값을 투명하게 처리하도록 하며, 수동 위임을 위한 루프와 send() 사용과는 어떻게 다릅니까?
yield from 구문은 반복뿐만 아니라 전체 제너레이터 프로토콜을 하위 제너레이터에 위임합니다. 외부 제너레이터가 yield from subgen()을 실행할 때, CPython은 호출자의 send(value)를 하위 제너레이터에 직접 보냅니다. 이 시점에서 하위 제너레이터가 StopIteration을 발생시키면, 그 값이 yield from 표현의 결과가 됩니다. 이는 수동 위임과의 차이점이 있습니다. 수동 위임에서는 for x in subgen(): yield x와 같이 루프가 외부 제너레이터에 보내진 값을 가로채서 내재제너레이터에 전달할 수 없습니다. yield from 구성은 호출 스택을 평탄화하여 임의로 깊은 제너레이터 중첩을 통해 양방향 데이터 흐름을 가능하게 하며, 보일러플레이트 전달 코드를 유지하지 않으면서 적절한 예외 전파 및 종료 의미론을 유지합니다.