# Розробка з asyncio

Асинхронне програмування відрізняється від класичного «послідовного» програмування.

На цій сторінці наведено типові помилки та пастки та пояснено, як їх уникнути.

## Режим налагодження

За замовчуванням asyncio працює у робочому режимі. Щоб полегшити розробку, asyncio має режим налагодження.

Є кілька способів увімкнути асинхронний режим налагодження:

- Встановлення змінної середовища `PYTHONASYNCIODEBUG` на `1`.

- Використання режиму розробки Python.

- Передача `debug=True` до `asyncio.run()`.

- Виклик `loop.set_debug()`.

Окрім увімкнення режиму налагодження, враховуйте також:

- setting the log level of the asyncio logger to `logging.DEBUG`, for example the following snippet of code can be run at startup of the application:

      logging.basicConfig(level=logging.DEBUG)

- налаштування модуля `warnings` для відображення попереджень `ResourceWarning`. Один із способів зробити це — скористатися параметром командного рядка `-W` `default`.

Коли ввімкнено режим налагодження:

- Багато небезпечних для потоків асинхронних API (таких як методи `loop.call_soon()` і `loop.call_at()`) викликають виняток, якщо вони викликаються з неправильного потоку.

- Час виконання селектора введення-виведення реєструється, якщо виконання операції введення-виведення займає надто багато часу.

- Callbacks taking longer than 100 milliseconds are logged. The `loop.slow_callback_duration` attribute can be used to set the minimum execution duration in seconds that is considered «slow».

## Паралельність і багатопотоковість

Цикл подій виконується в потоці (зазвичай головному) і виконує всі зворотні виклики та завдання у своєму потоці. Поки Завдання виконується в циклі подій, жодні інші Завдання не можуть виконуватися в тому самому потоці. Коли Завдання виконує вираз `очікування`, запущене Завдання призупиняється, а цикл подій виконує наступне Завдання.

Щоб запланувати callback з іншого потоку ОС, слід використовувати метод `loop.call_soon_threadsafe()`. Приклад:

    loop.call_soon_threadsafe(callback, *args)

Майже всі асинхронні об’єкти не є потокобезпечними, що зазвичай не є проблемою, якщо немає коду, який працює з ними поза Завданням або зворотним викликом. Якщо існує потреба в такому коді для виклику низькорівневого асинхронного API, слід використовувати метод `loop.call_soon_threadsafe()`, наприклад:

    loop.call_soon_threadsafe(fut.cancel)

Щоб запланувати об’єкт співпрограми з іншого потоку ОС, слід використати функцію `run_coroutine_threadsafe()`. Він повертає `concurrent.futures.Future` для доступу до результату:

    async def coro_func():
         return await asyncio.sleep(1, 42)

    # Later in another OS thread:

    future = asyncio.run_coroutine_threadsafe(coro_func(), loop)
    # Wait for the result:
    result = future.result()

To handle signals the event loop must be run in the main thread.

The `loop.run_in_executor()` method can be used with a `concurrent.futures.ThreadPoolExecutor` or `InterpreterPoolExecutor` to execute blocking code in a different OS thread without blocking the OS thread that the event loop runs in.

There is currently no way to schedule coroutines or callbacks directly from a different process (such as one started with `multiprocessing`). The Event loop methods section lists APIs that can read from pipes and watch file descriptors without blocking the event loop. In addition, asyncio’s Subprocess APIs provide a way to start a process and communicate with it from the event loop. Lastly, the aforementioned `loop.run_in_executor()` method can also be used with a `concurrent.futures.ProcessPoolExecutor` to execute code in a different process.

## Запуск коду блокування

Код блокування (прив’язаний до процесора) не слід викликати безпосередньо. Наприклад, якщо функція виконує інтенсивне обчислення ЦП протягом 1 секунди, усі одночасні асинхронні завдання та операції введення-виведення будуть відкладені на 1 секунду.

An executor can be used to run a task in a different thread, including in a different interpreter, or even in a different process to avoid blocking the OS thread with the event loop. See the `loop.run_in_executor()` method for more details.

## Лісозаготівля

asyncio використовує модуль `logging`, і все журналювання виконується через `"asyncio"` реєстратор.

The default log level is `logging.INFO`, which can be easily adjusted:

    logging.getLogger("asyncio").setLevel(logging.WARNING)

Network logging can block the event loop. It is recommended to use a separate thread for handling logs or use non-blocking IO. For example, see Робота з обробниками, які блокують.

## Виявляти ніколи не очікувані співпрограми

Коли функція співпрограми викликається, але не очікується (наприклад, `coro()` замість `await coro()`) або співпрограма не запланована за допомогою `asyncio.create_task()`, asyncio видасть `RuntimeWarning`:

    import asyncio

    async def test():
        print("never scheduled")

    async def main():
        test()

    asyncio.run(main())

Вихід:

    test.py:7: RuntimeWarning: coroutine 'test' was never awaited
      test()

Вивід у режимі налагодження:

    test.py:7: RuntimeWarning: coroutine 'test' was never awaited
    Coroutine created at (most recent call last)
      File "../t.py", line 9, in <module>
        asyncio.run(main(), debug=True)

      < .. >

      File "../t.py", line 7, in main
        test()
      test()

Звичайним виправленням є або очікування співпрограми, або виклик функції `asyncio.create_task()`:

    async def main():
        await test()

## Виявлення ніколи не отриманих винятків

Якщо викликається `Future.set_exception()`, але об’єкт Future ніколи не очікується, виняток ніколи не поширюватиметься на код користувача. У цьому випадку asyncio створюватиме повідомлення журналу, коли об’єкт Future збиратиме сміття.

Приклад необробленого винятку:

    import asyncio

    async def bug():
        raise Exception("not consumed")

    async def main():
        asyncio.create_task(bug())

    asyncio.run(main())

Вихід:

    Task exception was never retrieved
    future: <Task finished coro=<bug() done, defined at test.py:3>
      exception=Exception('not consumed')>

    Traceback (most recent call last):
      File "test.py", line 4, in bug
        raise Exception("not consumed")
    Exception: not consumed

Увімкніть режим налагодження, щоб отримати відстеження місця створення завдання:

    asyncio.run(main(), debug=True)

Вивід у режимі налагодження:

    Task exception was never retrieved
    future: <Task finished coro=<bug() done, defined at test.py:3>
        exception=Exception('not consumed') created at asyncio/tasks.py:321>

    source_traceback: Object created at (most recent call last):
      File "../t.py", line 9, in <module>
        asyncio.run(main(), debug=True)

    < .. >

    Traceback (most recent call last):
      File "../t.py", line 4, in bug
        raise Exception("not consumed")
    Exception: not consumed

## Asynchronous generators best practices

Writing correct and efficient asyncio code requires awareness of certain pitfalls. This section outlines essential best practices that can save you hours of debugging.

### Close asynchronous generators explicitly

It is recommended to manually close the asynchronous generator. If a generator exits early - for example, due to an exception raised in the body of an `async for` loop - its asynchronous cleanup code may run in an unexpected context. This can occur after the tasks it depends on have completed, or during the event loop shutdown when the async-generator’s garbage collection hook is called.

To avoid this, explicitly close the generator by calling its `aclose()` method, or use the `contextlib.aclosing()` context manager:

    import asyncio
    import contextlib

    async def gen():
      yield 1
      yield 2

    async def func():
      async with contextlib.aclosing(gen()) as g:
        async for x in g:
          break  # Don't iterate until the end

    asyncio.run(func())

As noted above, the cleanup code for these asynchronous generators is deferred. The following example demonstrates that the finalization of an asynchronous generator can occur in an unexpected order:

    import asyncio
    work_done = False

    async def cursor():
        try:
            yield 1
        finally:
            assert work_done

    async def rows():
        global work_done
        try:
            yield 2
        finally:
            await asyncio.sleep(0.1) # imitate some async work
            work_done = True

    async def main():
        async for c in cursor():
            async for r in rows():
                break
            break

    asyncio.run(main())

For this example, we get the following output:

    unhandled exception during asyncio.run() shutdown
    task: <Task finished name='Task-3' coro=<<async_generator_athrow without __name__>()> exception=AssertionError()>
    Traceback (most recent call last):
      File "example.py", line 6, in cursor
        yield 1
    asyncio.exceptions.CancelledError

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "example.py", line 8, in cursor
        assert work_done
               ^^^^^^^^^
    AssertionError

The `cursor()` asynchronous generator was finalized before the `rows` generator - an unexpected behavior.

The example can be fixed by explicitly closing the `cursor` and `rows` async-generators:

    async def main():
        async with contextlib.aclosing(cursor()) as cursor_gen:
            async for c in cursor_gen:
                async with contextlib.aclosing(rows()) as rows_gen:
                    async for r in rows_gen:
                        break
                break

### Create asynchronous generators only when the event loop is running

It is recommended to create asynchronous generators only after the event loop has been created.

To ensure that asynchronous generators close reliably, the event loop uses the `sys.set_asyncgen_hooks()` function to register callback functions. These callbacks update the list of running asynchronous generators to keep it in a consistent state.

When the `loop.shutdown_asyncgens()` function is called, the running generators are stopped gracefully and the list is cleared.

The asynchronous generator invokes the corresponding system hook during its first iteration. At the same time, the generator records that the hook has been called and does not call it again.

Therefore, if iteration begins before the event loop is created, the event loop will not be able to add the generator to its list of active generators because the hooks are set after the generator attempts to call them. Consequently, the event loop will not be able to terminate the generator if necessary.

Consider the following example:

    import asyncio

    async def agenfn():
        try:
            yield 10
        finally:
            await asyncio.sleep(0)

    with asyncio.Runner() as runner:
        agen = agenfn()
        print(runner.run(anext(agen)))
        del agen

Вихід:

    10
    Exception ignored while closing generator <async_generator object agenfn at 0x000002F71CD10D70>:
    Traceback (most recent call last):
      File "example.py", line 13, in <module>
        del agen
            ^^^^
    RuntimeError: async generator ignored GeneratorExit

This example can be fixed as follows:

    import asyncio

    async def agenfn():
        try:
            yield 10
        finally:
            await asyncio.sleep(0)

    async def main():
        agen = agenfn()
        print(await anext(agen))
        del agen

    asyncio.run(main())

### Avoid concurrent iteration and closure of the same generator

Async generators may be reentered while another `__anext__()` / `athrow()` / `aclose()` call is in progress. This may lead to an inconsistent state of the async generator and can cause errors.

Let’s consider the following example:

    import asyncio

    async def consumer():
        for idx in range(100):
            await asyncio.sleep(0)
            message = yield idx
            print('received', message)

    async def amain():
        agenerator = consumer()
        await agenerator.asend(None)

        fa = asyncio.create_task(agenerator.asend('A'))
        fb = asyncio.create_task(agenerator.asend('B'))
        await fa
        await fb

    asyncio.run(amain())

Вихід:

    received A
    Traceback (most recent call last):
      File "test.py", line 38, in <module>
        asyncio.run(amain())
        ~~~~~~~~~~~^^^^^^^^^
      File "Lib/asyncio/runners.py", line 204, in run
        return runner.run(main)
               ~~~~~~~~~~^^^^^^
      File "Lib/asyncio/runners.py", line 127, in run
        return self._loop.run_until_complete(task)
               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
      File "Lib/asyncio/base_events.py", line 719, in run_until_complete
        return future.result()
               ~~~~~~~~~~~~~^^
      File "test.py", line 36, in amain
        await fb
    RuntimeError: anext(): asynchronous generator is already running

Therefore, it is recommended to avoid using asynchronous generators in parallel tasks or across multiple event loops.