YL
иногда подход, который был описан в том примере может помочь. ну когда ты просто делаешь create_tast(coro()) и даёшь возможность лупу самому с ней работать в свободное время
Size: a a a
2019 April 01
YL
минус в том, что если ты это не заэвэйтишь - то исключения возникшие в этом таске никуда не передадутся
MG
Получается, выполнится задача хорошо, не выполнится тоже хорошо, если не await тить
YL
сорт оф - да
YL
в стдерр ты мб получишь сообщение от асинкайо в виде "был эксепшн в такой-то таске, но никто его не увидит"
MG
понял.
MG
А как насчет с ресурсоемкими задачами? блокирующими
YL
их лучше в пуле процессов
VS
А как насчет с ресурсоемкими задачами? блокирующими
Ну у тебя вычисления будут менеджерами ОС распределяться во времени. От них ты никуда не денешься, если у тебя в распоряжении только одно ядро процессора
MG
Через Subprocesses нужно будет их запускать верно?
YL
нет, ты создаёшь пулл процессов и делаешь loop.run_in_executor
VS
Через Subprocesses нужно будет их запускать верно?
В контексте других концепций - да, но текущий контекст - async python
MG
Ок. Попробую сделать сегодня.
VS
В идеале делегировать такие вычисления другим компонентам
2019 April 07
ຸ
Всем доброго вечера, я тут захотел прикрутить к своєму скрипту API, что бы запускать ремоутно и задумался об асинхроности. Никогда особо в пайтоне с ней не работал. Но вопрос примерно такой я хочу на пост апи запускать свой скрипт и возращать 202 а скрипт потом запишет результат в базу. Как лучше запускать скрипт asyncio или просто запустить с os.system/subprocess или concurrent.futures?
🇧S
По-разному можно, есть еще celery
BG
Всем доброго вечера, я тут захотел прикрутить к своєму скрипту API, что бы запускать ремоутно и задумался об асинхроности. Никогда особо в пайтоне с ней не работал. Но вопрос примерно такой я хочу на пост апи запускать свой скрипт и возращать 202 а скрипт потом запишет результат в базу. Как лучше запускать скрипт asyncio или просто запустить с os.system/subprocess или concurrent.futures?
Так вроде лучше не делать
BG
Ну, если я правильно понял, вы хотите сначала ответить, а потом записать в базу. Мое имхо, лучше сначала таки хоть что-то записать в базу и потом уже ответить
ຸ
Да, но запись в базу как раз не влияет особо, я использую rocksdb и насколько я понял все write операции асинхронны по дефолту. Мне скорее было интересно бестпрактис для запуска одного ресурсоемкого скрипта через api, я еще думаю как лучше сделать api aiohttp или flask threaded или falsk с gevent. Я понимаю, что все решения подходят в той или иной мере, просто абсурдное желание найти самый лучший вариант 🙂
BG
Суть в том, что если вы начинаете какую-то сложную операцию, по идее имеет смысл трекать ее статус в персистентном хранилище. То есть если вы ответите по api, что все ОК, а потом запись в бд упадет - это как бы будет очень плохо