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로 현재 설치된 핸들러를 실행합니다. 대부분 루프 자체가 사용하며, 애플리케이션이 필요로 하는 경우는 드뭅니다.