8.13. Loopkontroll#

De flesta asyncio-skript rör aldrig händelseloopen direkt – asyncio.run() räcker. Den här sidan täcker Loop-gränssnittet för de fall där det inte räcker: att installera en undantagshanterare, köra loopen med en annan livscykel än run, eller behålla loopobjektet för instrumentering.

8.13.1. Att hämta loopen#

  • asyncio.get_event_loop() – returnerar Loop-objektet. Säkert att anropa både inifrån och utanför en coroutine.

  • asyncio.new_event_loop() – på MicroPython återställer den befintliga loopens tillstånd snarare än att skapa en ny. Anmärkningen tål att upprepas: det finns exakt en händelseloop per program.

Det finns inget API för att köra loopen annat än metoderna på Loop och asyncio.run().

8.13.2. Att köra loopen direkt#

asyncio.run() är rätt ingångspunkt för nästan varje applikation. Två Loop-metoder finns för de fall där den inte är det.

  • run_until_complete() – givet en inväntbar, kör loopen tills den inväntbara är klar och returnera sedan dess resultat. Motsvarar ett enda anrop till asyncio.run(), men utan att loopen rivs ned.

  • run_forever() – kör loopen tills stop() anropas inifrån en uppgift. Ingen inväntbar på toppnivå; applikationen förväntas schemalägga vad den än behöver via asyncio.create_task() innan run_forever anropas.

Kompletterande metoder är stop() (begär att loopen stoppar efter att den aktuella uppgiften är klar) och close() (frigör loopens resurser).

8.13.3. Uppgiftsskapande på loop-sidan#

  • create_task() – samma operation som asyncio.create_task(). Den fristående funktionen finns så att applikationskod inte behöver en loopreferens i det vanliga fallet; metoden finns för instrumentering som redan har en.

8.13.4. Undantagshanterare#

Loopen anropar en hanterare när en uppgift höjer ett undantag som inget i coroutinens anropskedja har fångat – ett typiskt fall är en uppgift som applikationen skapade med asyncio.create_task() och aldrig inväntade. Standardhanteraren skriver ut en spårning via sys.stderr; sidan om undantag visade hur man byter ut den mot något anpassat.

  • set_exception_handler() – installera en anpassad hanterare. Hanteraren är ett anropbart handler(loop, context) där context är en dict med åtminstone 'message' och vanligtvis 'exception' och 'future'.

  • get_exception_handler() – returnerar den för närvarande installerade hanteraren, eller None om standardhanteraren används.

  • default_exception_handler() – den inbyggda hanteraren. Användbar inuti en anpassad hanterare som vill köra även standardbeteendet (logga till flashminne och skriva ut en spårning, till exempel).

  • call_exception_handler() – kör den för närvarande installerade hanteraren med en handbyggd context-dict. Används mestadels av loopen själv; en applikation behöver den sällan.