8.15. Pułapki#

Te same wzorce, które czynią asyncio przyjemnym – brak wywłaszczania, jawne await – nadają mu też własny zestaw kształtów, które potrafią ugryźć. Ta strona jest katalogiem tych, które pojawiają się na tyle często, by warto było je znać.

8.15.1. Zapomnienie o await#

Wywołanie funkcji async def zwraca obiekt korutyny. Nie uruchamia ono ciała funkcji. Aby faktycznie ją wykonać, na korutynie trzeba wykonać await lub opakować ją w zadanie:

async def main():
    send_request()              # bug: returns the coroutine, does nothing
    await send_request()        # right: run it to completion
    asyncio.create_task(send_request())  # right: run it concurrently

Błąd jest cichy – obiekt korutyny zostaje utworzony, porzucony i nigdy niewykonany. Aplikacja działa dalej, jakby wszystko zadziałało. MicroPython czasem rejestruje ostrzeżenie, że na korutynie nigdy nie wykonano await; czasem nie. Sprawdzaj brakujące await w każdym miejscu wywołania, które wygląda jak wywołanie funkcji.

8.15.2. Ciasne pętle bez await#

Korutyna działająca w pętli i nigdy niewykonująca await zawłaszcza pętlę zdarzeń. Żadne inne zadanie nie robi postępów, dopóki pętla się nie zakończy lub nie odda sterowania:

async def counter():
    n = 0
    while True:
        n += 1               # bug: starves the loop

Naprawą jest oddanie sterowania (yield) wewnątrz pętli – zazwyczaj await asyncio.sleep_ms(0) – aby inne gotowe zadania dostały szansę na działanie. Obliczeniowo wymagająca praca również należy do tego schematu: pętla przetwarzania obrazu działająca po setki milisekund na iterację powinna oddawać sterowanie co najmniej raz na iterację, aby reszta programu się nie zacinała.

8.15.3. Połykanie CancelledError#

Strona o anulowaniu omówiła to już szczegółowo. Powtarzamy to tutaj, ponieważ jest to najczęstsza przyczyna sytuacji „moja aplikacja nie chce się wyłączyć”: korutyna przechwytuje asyncio.CancelledError w celu sprzątania i zapomina go ponownie zgłosić. Zadanie działa dalej; wywołujący, który zażądał anulowania, wisi w nieskończoność, czekając na jego zakończenie. Zawsze ponownie zgłaszaj wyjątek po sprzątaniu lub użyj bloku try/finally zamiast jawnego except.

8.15.4. Mutowanie współdzielonego stanu pomiędzy await#

Harmonogramowanie kooperatywne gwarantuje, że korutyna ma CPU dla siebie pomiędzy await, ale gdy tylko wykona await, może uruchomić się inna korutyna. Jeśli dwie korutyny modyfikują tę samą strukturę danych w krokach zawierających await, ich operacje mogą się przeplatać w sposób uszkadzający strukturę:

# bug: two tasks running do_work simultaneously can
# interleave around the await and corrupt items
async def do_work():
    n = len(items)
    await asyncio.sleep_ms(0)
    items.append(some_work(n))

Dla stanu mutowanego wyłącznie pomiędzy await wewnątrz jednej korutyny żadna synchronizacja nie jest potrzebna. Dla stanu mutowanego pomiędzy await i dostępnego z więcej niż jednej korutyny opakuj sekcję krytyczną w Lock.

8.15.5. await na poziomie modułu#

await jest poprawne tylko wewnątrz ciała async def. Zapisanie go na poziomie modułu – poza jakąkolwiek korutyną – jest błędem składni:

# bug: not inside an async def
result = await fetch()

Naprawą jest umieszczenie pracy w korutynie i wywołanie jej z punktu wejścia programu asyncio.run().

8.15.6. Wielokrotne wywołania asyncio.run#

MicroPython ma jedną pętlę zdarzeń. Dwukrotne wywołanie asyncio.run() z rzędu – raz na konfigurację, raz na główną pracę – nadal korzysta z tej samej pętli. Wywołanie go z wnętrza działającej korutyny jest błędem: pętla już działa. Oba przypadki pojawiają się najczęściej, gdy skrypt rozrasta się organicznie, a autor próbuje go rozszerzyć, dodając kolejne wywołania run() zamiast włączyć nową pracę do istniejącego main.

8.15.7. Użycie Event z przerwania#

asyncio.Event.set() można bezpiecznie wywołać tylko z wnętrza pętli zdarzeń. Wywołanie go z funkcji obsługi przerwania GPIO grozi uszkodzeniem danych. Do wybudzania zadania z przerwania użyj zamiast tego ThreadSafeFlag – strona o nim omawia ten schemat.

8.15.8. Długie wywołania synchroniczne#

Korutyna może wykonać await na własnych prymitywach oczekiwania asyncio; wszystko inne, co wywoła, działa synchronicznie i blokuje pętlę do momentu powrotu. Blokujący time.sleep() na 200 ms, zapis na kartę SD trwający 80 ms do opróżnienia, duża kompresja JPEG, wywołanie csi.CSI.snapshot() – każde z nich trzyma pętlę zdarzeń przez cały swój czas trwania. Naprawa zależy od wywołania:

  • Dla time.sleep: zastąp je przez await asyncio.sleep lub await asyncio.sleep_ms.

  • Dla csi.CSI.snapshot: użyj asynchronicznego wrappera zrzutu obrazu, który buduje strona o przechwytywaniu.

  • Dla długich obliczeń (przetwarzanie obrazu, kodowanie JPEG): zaakceptuj koszt lub podziel pracę na fragmenty wykonujące await pomiędzy iteracjami.

Asyncio nie może uczynić wywołania synchronicznego nieblokującym. Może jedynie pozwolić innym korutynom działać podczas, gdy coś innego oczekuje.