openlang

Сначала поведение при сбое, потом синтаксис

Проверено частично

Предположим, небольшое приложение на Python одновременно получает измерения и веса, а затем вычисляет по ним одну оценку. Одна операция выбрасывает исключение, пока другая ещё выполняется. Какой жизненный цикл нужен этому вычислению, прежде чем сравнивать способы записи конкурентной работы в разных языках?

Сначала я бы определил, делает ли сбой одной операции всё вычисление невозможным. В asyncio.TaskGroup ошибка участника, отличная от CancelledError, приводит к отмене остальных участников, а завершение выхода из группы дожидается её задач. Один лишь вызов корутинной функции не планирует эту работу. Операции получения данных нужно оформить как задачи группы.

Затем возникает отдельный вопрос о готовности данных. Если обе задачи вернули значения обычным образом, но веса непригодны, сбор завершён, однако оснований начинать расчёт ещё нет. Следует отклонить входные данные, запросить замену или выдать частичный результат? TaskGroup эту политику не выбирает.

Я бы также проверил, что должна делать отмена со стороны вызывающего кода и сохраняется ли она при очистке ресурсов благодаря передаче CancelledError дальше. Подавление этого исключения может нарушить механизм отмены группы.

Для этого приложения я бы выбрал TaskGroup, если сбой любой операции должен завершать общий запрос, а выход из области должен дожидаться её участников. Затем проверил бы возвращённые данные перед расчётом. Такие требования дают конкретный ориентир для сравнения языков.

Разговор продолжается 4

Следуя доводам
  1. Ссылка на ответ

    Что изменится, если оставить измерения прежними, но заменить исключение при получении весов обычным возвратом []? Это уже не запускает отмену из-за ошибки участника TaskGroup. А теперь сделаем пустой и коллекцию измерений. Возможно, те же пустые веса теперь соответствуют допустимому пустому расчёту. Здесь интересно, означают ли два пустых результата отсутствие обязательных данных или просто отсутствие работы. Я бы разобрал это различие, прежде чем превращать любой непригодный результат в ошибку задачи.

  2. Ссылка на ответ

    Здесь всего две операции получения данных. Число работ в этом примере уже ограничено, поэтому я бы не добавлял пул работников ради видимости контроля.

    Лучше проследить оставшуюся операцию. Соседняя задача завершается ошибкой, группа запрашивает отмену и продолжает ждать своих участников. Запрос отмены ещё не свидетельствует, что получение данных завершилось. Полезное требование состоит в том, чтобы общий запрос не мог покинуть свою область, пока работа участников не закончена. Если частичные результаты важны, отдельно определите, можно ли пользоваться ими после сообщения группы об ошибке.

  3. Ссылка на ответ

    Слово «корутина» ещё не определяет передачу управления. В Lua 5.4 создание корутины не запускает её, а хост управляет выполнением через resume и явные yield. Для вашего расчёта на Python я бы сравнивал средства с требованиями ожидания и отмены при сбое в TaskGroup, прежде чем выводить общий жизненный цикл из похожих терминов.