import asyncio async def compute(x, y): print("Compute %s + %s ..." % (x, y)) await asyncio.sleep(1.0) return x + y async def print_sum(x, y): result = await compute(x, y) print("%s + %s = %s" % (x, y, result)) loop = asyncio.get_event_loop() loop.run_until_complete(print_sum(1, 2)) loop.close()
Полная версия: Блокирующий или не блокирующий код в asyncio?
Здравствуйте уважаемые форумчане, разъясните пожалуйста пример из документации. Есть вот такой код:
На картинке изображена диаграмма запуска сопрограмм. Так вот во всех примерах из документации встречается asyncio.sleep(секунды) для того чтобы мол показать трудоёмкие вычисления. И во время исполнения asyncio.sleep() управление переходит Задаче, а потом и Циклу событий (судя по диаграмме). Так вот вопрос. Если в сопрограмме compute() не использовать asyncio.sleep() а например действительно вычисления длительные по времени, то управление не перейдёт Циклу событий, а будет исполняться до вычисления результата, по сути это будет блокирующий код? И как я понял, функция sleep от asyncio это какая то хитрая функция исполняемая Циклом событий? Что то в доках я ясного ответа не нашёл.
блин нечаянно поместил вопрос в раздел “для экспертов” 
zip1982bневерно, не трудоемкие, а имеющие операции ввода/вывода - по сути когда процесс простаивает ожидая ответ. В случае трудоемких задач асинхронность плавно перетекает в синхронность т.е. никаких переключений на другие задачи в этом смысле не будет.
для того чтобы мол показать трудоёмкие вычисления
asyncio.sleep используется исключительно для эмуляции IO издержек, возьмите обычный time.sleep и сэмитируете блокирующие переключения вычисления.
то есть по сути, сопрограмма compute() должна быть future объектом в случае I\O?
Получается что только в операциях I\O может быть возврат управления Циклу событий, чтобы он мог запустить другие задачи?
по поводу asyncio.sleep() в документашке нашёл что создаётся внутренний (я так понимаю, скрытый от нас) future который использует call_later() для того чтобы разбудить задачу.
Получается что только в операциях I\O может быть возврат управления Циклу событий, чтобы он мог запустить другие задачи?
по поводу asyncio.sleep() в документашке нашёл что создаётся внутренний (я так понимаю, скрытый от нас) future который использует call_later() для того чтобы разбудить задачу.
zip1982bДа. Главное Вам уяснить что асинхронность это не про тяжелые задачи - это пожалуй самая частая ошибка в понимании этой технологии.
Получается что только в операциях I\O может быть возврат управления Циклу событий, чтобы он мог запустить другие задачи?
На предприятии имеются контроллеры в количестве 230 штук. Они поддерживают свой протокол (фирменный) поверх tcp\ip и слушают порт 4545. На них (контроллерах) реализован сервер этого протокола. После отправки разрешения на соединение и получения от контроллера подтверждения что соединение установлено (фирм протокол), мне необходимо подписаться (предусмотрено фирменным протоколом) на определённые события которые могут произойти в контроллере. И если эти события происходят, то контроллер отсылает инфу о событии. Так вот эти события и необходимо принять на моём компьютере клиенте. До asyncio, при использовании мной обычного кода клиент как бы зависал. После этого я начал смотреть в сторону asyncio. Скажите JOHN_16 данная задача входит в разряд I\O? И должна решаться методами асинхронного программирования? На мой взгляд, да. При том, что я хочу чтобы был один клиент (компьютер производящий анализ) и много контроллеров - серверов отсылающих данные по событию. По обработке данных пришедших от серверов, там тяжёлых задач (имеющих длительные вычисления и блокирующих код) не предвидится. Возможно в будущем необходимо будет заносить определённые данные в БД. Как то так.
JOHN_16 я благодарен за ваши поправки и ответы.
JOHN_16 я благодарен за ваши поправки и ответы.
> На предприятии имеются контроллеры в количестве 230 штук.
Потоки не пробовал?
Потоки не пробовал?
RodegastЯ бы у ТС уточнил, планируется увеличение количества машин? 230 это уже довольно много потоков. Может памяти не хватить на слабенькой машине.
Потоки не пробовал?
Еще вопрос насколько часто возникают события и сколько времени требует обработка.
zip1982bПо терминологии. Если контроллеры активно шлют забросы на обработку данных то по отношению к вашей системе они клиенты а не сервера а ваш центральный комп сервер а не клиент.
серверов отсылающих данные
С потоками много проблем (GIL). Хотя это не мои мысли (читаю блог Светлова).
Контроллер может одновременно поддерживать связь с пятью клиентами, я уже подумывал, чтобы для одних задач поставить один компьютер с программой, а для других задач (сохранение результатов в БД) другой комп.
Я бы у ТС уточнил, планируется увеличение количества машин?Да, со временем планируется, когда достроят новые цеха.
По терминологии. Если контроллеры активно шлют забросы на обработку данных то по отношению к вашей системе они клиенты а не сервера а ваш центральный комп сервер а не клиент.Может Вы и правы, но в описании к протоколу (Open Protocol фирмы Atlas Copco) сказано обратное (смотреть рисунок). Дело в том что протокол предусматривает довольно обширные возможности для управления контроллером. Можно работать с ним в режиме спросил, получил ответ (тут чисто клиент - серверное взаимодействие), а можно установил с ним соединение (методами протокола) и подписался на оповещение в случае определённых событий (событий тоже может быть несколько). В случае когда линия сборки работает, то события происходят часто (пример: Неудачно выполнена затяжка болтового соединения или оператор просканировал вин номер на кузове автомобиля - необходимо получит этот вин номер, проанализировать его и указать контроллеру какую программу выбрать для данного типа авто). В случае когда линия стоит (перерыв или пересменка) появление событий может достигать значительного времени (20-30 минут).
Контроллер может одновременно поддерживать связь с пятью клиентами, я уже подумывал, чтобы для одних задач поставить один компьютер с программой, а для других задач (сохранение результатов в БД) другой комп.
asyncio начал изучать недавно и думаю что реальные задачи будут способствовать лучшему освоению и пониманию асинхронного программирования. Хотя не раз убеждаюсь, что не стоит держаться за определённые технологии, необходимо отталкиваться от потребностей. Это так мысли в слух.