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.