8.13. 루프 제어

대부분의 asyncio 스크립트는 이벤트 루프를 직접 다루지 않습니다 – asyncio.run()으로 충분합니다. 이 페이지는 그것으로 충분하지 않은 경우, 즉 예외 핸들러를 설치하거나, run과 다른 생명 주기로 루프를 실행하거나, 계측을 위해 루프 객체를 보유하는 경우를 위한 Loop 표면을 다룹니다.

8.13.1. 루프 얻기

  • asyncio.get_event_loop() – Loop 객체를 반환합니다. 코루틴 내부에서든 외부에서든 안전하게 호출할 수 있습니다.

  • asyncio.new_event_loop() – MicroPython에서는 새 루프를 생성하는 것이 아니라 기존 루프의 상태를 재설정합니다. 이 주의 사항은 반복할 가치가 있습니다: 프로그램당 이벤트 루프는 정확히 하나입니다.

Loop의 메서드와 asyncio.run() 외에 루프를 실행하는 API는 없습니다.

8.13.2. 루프를 직접 실행하기

asyncio.run()은 거의 모든 애플리케이션에 적합한 진입점입니다. 그것으로 충분하지 않은 경우를 위해 두 개의 Loop 메서드가 존재합니다.

  • run_until_complete() – awaitable이 주어지면, 그 awaitable이 끝날 때까지 루프를 실행한 뒤 그 결과를 반환합니다. 단일 asyncio.run() 호출과 동등하되, 루프 해체 부분이 빠진 것입니다.

  • run_forever() – 태스크 내부에서 stop()이 호출될 때까지 루프를 실행합니다. 최상위 awaitable이 없으며, 애플리케이션은 run_forever를 호출하기 전에 asyncio.create_task()를 통해 필요한 것을 스케줄링해야 합니다.

동반 메서드로는 stop()(현재 태스크가 끝난 후 루프를 멈추도록 요청)과 close()(루프의 리소스를 해제)가 있습니다.

8.13.3. 루프 측 태스크 생성

  • create_task() – asyncio.create_task()와 동일한 작업입니다. 자유 함수는 일반적인 경우에 애플리케이션 코드가 루프 참조를 필요로 하지 않도록 존재하고, 메서드는 이미 루프 참조를 가진 계측을 위해 존재합니다.

8.13.4. 예외 핸들러

루프는 코루틴 호출 체인 어디에서도 잡히지 않은 예외를 태스크가 발생시켰을 때 핸들러를 호출합니다 – 전형적인 경우는 애플리케이션이 asyncio.create_task()로 생성하고 한 번도 await하지 않은 태스크입니다. 기본 핸들러는 sys.stderr를 통해 트레이스백을 출력합니다. 예외 페이지에서 이를 사용자 정의 핸들러로 교체하는 방법을 보여주었습니다.

  • set_exception_handler() – 사용자 정의 핸들러를 설치합니다. 핸들러는 호출 가능한 handler(loop, context)이며, 여기서 context는 최소한 'message'를 포함하고 보통 'exception'과 'future'를 포함하는 dict입니다.

  • get_exception_handler() – 현재 설치된 핸들러를 반환하거나, 기본 핸들러가 사용 중이면 None을 반환합니다.

  • default_exception_handler() – 내장 핸들러입니다. 기본 동작도 함께 실행하려는 사용자 정의 핸들러 내부에서 유용합니다(예를 들어 플래시에 로그를 남기는 동시에 트레이스백을 출력).

  • call_exception_handler() – 직접 만든 context dict로 현재 설치된 핸들러를 실행합니다. 대부분 루프 자체가 사용하며, 애플리케이션이 필요로 하는 경우는 드뭅니다.