python3: чем заменить gevent?
беспощадность тредов это все-таки проблема CPython. В Jython и ironpython нет gil (и по слухам можно отключить gil в pypy, но я не пробовал но тут хз, подружатся ли с ними твои библиотеки.
В Jython и ironpythonНе, не вариант. ironpython по умолчанию в лейнуксах нет (приложение рассчитано в основном на лейнуксы, в первую очередь — убунта а jython, боюсь, вообще не взлетит со всеми этими GObject-introspection и прочими. Релизная версия застряла ещё на питоне 2.5, не умеет даже "except … as …" и поэтому падает на всех без исключения библиотеках, а предлагать массовому пользователю ставить превью jython, если под ним вдруг взлетит… ну я даже не знаю.
массовому пользователютогда не вариант. такие вещи бывают хороши для серверных приложений, когда достаточно собрать и завести окружение один раз.
вообще, если в твоей задаче эстонская тормознутость питона не фатальна, то может и многопоточность не сильно нужна?
Ну как не нужна. У меня есть окно на Gtk, которое, понятное дело, не должно подвисать, как это у всяких дельфи-разработчиков принято, и 30 провайдеров данных, которым я посылаю (всем) N запросов каждые 5 минут. В среднем, как мне кажется, у пользователей N=1 (трекается одна посылка бывает и больше.
Для некоторых говносайтов, чьи авторы любят ASP.NET, приходится делать по несколько запросов на задачу (потому что ASP.NET — тупое говно чаще по одному.
Т.е. получается примерно 40 запросов на одну трекаемую посылку. Как минимум их надо выносить отдельный тред, чтобы не блокировать гуй, как максимум, надо учитывать реальный мир — http-запрос в среднем выполняется около секунды, пока установишь соединение, пока распарсишь, пока у почты России SOAP с обеда выйдет, получается 40 секунд на полное обновление при последовательном выполнении. Если найдётся кто-то, следящий сразу за 7-8 посылками, то он уже будет жить в непрерывном цикле обновления.
Манкипатчинг гевента в этом плане удобен, потому что он фактически засовывает все сокеты в еполл и всем всё хорошо. Иначе надо писать свой еполл и поверх него наворачивать http(s)/soap.
Для некоторых говносайтов, чьи авторы любят ASP.NET, приходится делать по несколько запросов на задачу (потому что ASP.NET — тупое говно чаще по одному.
Т.е. получается примерно 40 запросов на одну трекаемую посылку. Как минимум их надо выносить отдельный тред, чтобы не блокировать гуй, как максимум, надо учитывать реальный мир — http-запрос в среднем выполняется около секунды, пока установишь соединение, пока распарсишь, пока у почты России SOAP с обеда выйдет, получается 40 секунд на полное обновление при последовательном выполнении. Если найдётся кто-то, следящий сразу за 7-8 посылками, то он уже будет жить в непрерывном цикле обновления.
Манкипатчинг гевента в этом плане удобен, потому что он фактически засовывает все сокеты в еполл и всем всё хорошо. Иначе надо писать свой еполл и поверх него наворачивать http(s)/soap.
40 запросовТы не можешь на каждый запрос создавать отдельный процесс?
А зачем? Ну пусть вынесет интерфейс в отдельный процесс а запросы дёргает в другом. Плодить процессы там нафиг не нужно. Питоновских тредов хватит на ура. Ожидание ответа от http не блокирует же ничего в gil.
Ну или вот надстройка над популярной либой Requests - http://github.com/ross/requests-futures Я сам пользуюсь ей, но у меня существенно больше 40 запросов.
Ну или вот надстройка над популярной либой Requests - http://github.com/ross/requests-futures Я сам пользуюсь ей, но у меня существенно больше 40 запросов.
если нужна скорость то зачем питон? 
Ты не можешь на каждый запрос создавать отдельный процесс?Как уже предложили, а кто мешает делать новые питоновские треды? У меня есть питоновский GUI (написанный на wxPython который общается с несколькими микроконтроллерами, и они (микроконтроллеры) отвечают мне не сразу. Поэтому я на каждый запрос создаю новый тред, и когда ответ готов кидаю в основной GUI тред wxEvent (с присоединёнными данными который уже автоматически обрабатывается гуёвыми окошками (которые этот event слушают).
Так что мне кажется, что и в твоём pyGTK тоже можно всё аналогично реализовать.
Как уже предложили, а кто мешает делать новые питоновские тредыДелать не мешает никто. Можно и в отдельные треды, и в мультипроцессинг, и даже в subprocess подолбиться. Но хоть какое-то же чувство прекрасного должно быть!
Субъективно, но отдельные треды проще (и, этим, куда прекраснее) манкипатчинга и эвент-движка.
Но я говорю с позиции человека который переписывал ужасно эвент-движковый легаси-код на плюсах на потоки, после чего тот перестал течь и стал работать в разы эффективнее по ресурсам.
Но я говорю с позиции человека который переписывал ужасно эвент-движковый легаси-код на плюсах на потоки, после чего тот перестал течь и стал работать в разы эффективнее по ресурсам.
если нужна скорость то зачем питон?Если честно, за такой вопрос хочется уебать. Он сразу навевает мысли о тех макаках, которые пишут десктопные приложения на питоне именно с этой мыслью в голове — у нас питон, значит, нас уже не волнует скорость.
Я сам терпеть не могу питон, но: разработка полноценного приложения с хелпом, сборкой на ланчпаде и доставкой конечным пользователям заняла примерно два дня, поддержка вот уже на протяжении нескольких лет в основном сводится к паре часов раз в два месяца на написание нового парсера по заявкам пользователей.
Написав всё на сишечке, я бы уменьшил на порядок cpu time, да. Пользовательское время выполнения процессов уменьшилось бы на несколько процентов. А предложения вида «в питоне похуй на скорость, давайте всё делать последовательно» увеличивают уже пользовательское время на тот самый порядок.
на плюсахТреды в плюсах и треды в питоне — это джве большие разницы
Ну и да, корутины тоже надо уметь готовить, чо уж там.
Я в курсе. Но, тем не менее, даже в питоне я согласен с вышеотписавшимися — отдельные треды на запрос выглядят куда проще и логичнее исходя из (моих субъективных) wtf per minute.
Я в курсе. Но, тем не менее, даже в питоне я согласен с вышеотписавшимися — отдельные треды на запрос выглядят куда проще и логичнее исходя из (моих субъективных) wtf per minute.С точки зрения гевента это и выглядит как треды, ничем не отличается:
for service in enabled_searches:
gevent.spawn(fetch_parcel, service(postcode parcel_to_update, callback)
Ну а в "треде" мы просто читаем/пишем в сокеты средствами обычных библиотек. Просто сокет волшебный. Не вижу, где бы там образоваться WTF.
А вот 30..30N тредов для десктопной программы — это какая-то хуйня, ящетаю.
где бы там образоваться WTFВ манкипатчинге же.
А вот 30..30N тредов для десктопной программы — это какая-то хуйняПервое.
Правило.
Оптимизации.
Где хуйня? Почему хуйня? Где измерения этой хуйни?
Оптимизации.Я услышал, что скорее говорит сейчас о красоте кода ("плохом запахе кода" чем об оптимизации.
Вопросы в этом случае похожие:
Где "плохо пахнет"? Почему это воспринимается как "плохой запах"? Как измеряется "плохой запах"?
Оставить комментарий
doublemother
Суть проблемы: есть десктопное приложение, которое рисует гуй и дёргает пачку разных сетевых запросов для сбора и отрисовки информации — обычный GET/POST HTTP с разным набором заголовков (через httplib SOAP (через suds теоретически в будущем ещё может добавиться какая-нибудь херня со своей библиотекой. А хочется от всего этого асинхронности.Потоки в питоне, как известно, убогие, мультипроцессинг просто изначально ущербен.
С gevent я использовал манкипатчинг и все библиотеки сразу начинали работать асинхронно и удобно. Но в 1.0 автор сломал SSL и я задумался над переездом на что-то другое и сразу на питон3. Там вместо гевента пропагандируют asyncio, но кажется, что никакого манкипатчинга при этом у них не бывает, я по крайней мере не нашёл. И как при этом заставлять работать всякие библиотеки, которые на asyncio не заточены и всякие сокеты и операции с ними делают у себя внутри, непонятно. Писать новый asyncio-совместимый SOAP-клиент, как-то никакого желания.
Кто-нибудь в курсе, как в современном бедономире такие вещи принято делать?