Как вы вообще разрабатываете на питоне?

К реальным проектам мандельброт отношения не имеет, ты не числодробилки пишешь, затык всегда в БД или IO. А один поток питона спокойно обрабатывает тысячи запросов в секунду.

На многих проектах можно использовать кеширование. Запросов(даже автоматически http://django-cachalot.readthedocs.io/en/latest/), целых страниц.

Просто надо иструмент под задачу выбирать. Например, мы занимались iptv. RTSP сервер у нас был на C++, всякие интерфейсы для django. Телепрограммы(частый запрос) отдавались яваскрипту через модуль на си к nginx, который делал запрос в postgres напрямую и отдавал json, запись видео для паузы и записи телепрограмм - маленькая программа на си, которую запускал питон по расписанию. Распростронение фильмов между хранилищами с ними через модифицированный bittorrent. Балансировщик тоже на питоне. Для некоторых из этих штук можно было бы взять го, если бы он тогда был. Но для вебни смысла нет.

по совокупности факторов в питоне мультитрединг не пригоден к использованию.

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

таким образом, ты обязан синхронизировать _любой доступ_. даже

x += 1

1. проблема ли это? нет конечно. только вот трудозатрат, дисциплины и отладки у тебя как в полноценной многопоточной программе, а получаешь ты что? правильно - по сути дела однопоточную программу, т.к. остальные треды могут только ждать, делать что-то они не могут.

2. средства синхронизации в питоне убоги. то ли в жаве то ли в шарпе вроде были 1. неявные локи у любого обекта (чтобы не создавать и не поддерживать все эти списки/маппинги локов на ресурсы) 2. синтаксическая поддержка (в целом не так важно но всё же, и да контекст менеджеры как-то слабо выглядят) 3. частично авто-синхронизированне коллекции

в питоне этого нет

т.е. ты пишешь почти однопоточную программу, тратя сил как на настояющую многопоточную, причем инструменты у теья есть, они вполне нормальные, но не самые развитые (и понятно почему)

когда начинают на пустом месте городить redis, celery, ZMQ, микросервисы или обмен через БД

это не на пустом месте.

вероятно эта мода пошла из веба, а конкретно из пхп который вроде как долгое вермя был по определению именно шаред-нафинг (100%ный цги по концепции, но мод-пхп/фаст-цги по реализации).

во-вторых пхп по определнию долгое время был однопоточным, и вообще тёк.

т.е. возможности обработчикам двух хттп запросов пользоваться общими данными из оперативки банально не было.

но шаред-нафинг имеет огромные плюсы, нельзя забывать.

большинстве случаев у тебя будет не один сервер

это чушь. чтобы собственно код проекта (вынесенную БД мы не учтываем) не влез в один сервер - это крайне редко такое бывает. это или фейсбуки или идиоты или железо 20 летней давности.

Я имею ввиду, что это либо небольшой проект, где впски какой-нибудь хватает либо уже надо думать о мастштабировании дальше.

речь же шла трединге, вычислительной можности.

я так и не понял, а зачем за пределы одной машины выходить-то? я почти не знаю проектов, код которых не вместится в одну машину, кроме всяких яндексов, авито и т.п.

(отдельно стоящую субд это отдельно конечно).

Вы так говорите, будто питон это только веб, фласк и джанго всякое. Например, сервис, который получает запросы по unix socket. Да даже в том же вебе - есть у меня запрос с апи, которое выполняется ненулевое количество время, и мне нельзя запускать две такие задачи одновременно.

В golang я это сделал просто - глобальный map, защищаешь его mutex-ом, при добавлении в map проверяешь, если ли там запись с нужным ключём, и если нужно - футбольишь клиента\ставишь в очередь\игнорируешь.

А изначально я по-быстрому пытался накидать это на фласке. А в нём негде хранить такой глобальный стэйт, пришлось рядом ставить redis. Или городить варианты с отдельными воркерами (celery, или всякое поверх того же redis/mq).

В asyncio у тебя такой стейт есть. Если ты делаешь из него запросы к бд/другим api и т.п. можно делать асинхронно. Если что-то другое долгое есть processpoolexecutor и т.п.

это на фласке. А в нём негде хранить такой глобальный стэйт, пришлось рядом ставить redis.

может быть ты просто безграмотный идиот и не понимаешь азов программирования?

что конкретно препятствует держать в памяти шаред данные?

Вежливый анонимус, приятное общение. flask запускался через gunicorn, чтобы было несколько воркеров, а не один. Между соседними воркерами память не шарится. Хотя да, нужно будет погуглить для себя на будущее, может быть стоило запускать один инстанс, который получает запросы (даже без всяких gunicorn), а просто внутри создать нужное количество трэдов-воркеров...

позорник, твоя задача вполне решается в питоне. за 5 минут. можно даже с фласком.

не знаю, что такое gunicorn, с фласком тоже не работал.

ты говорил «во фласке нельзя шарить стейт»

так кто тебе мешает? http<->wsgi сервер? запускалка? фласк? сам питон?

воркеров

так воркеры - это процессы? так они и не могут шарить данные, чего ты ожидал? это ограничение фундаментальное, но причем тут фласк? ты думал фласк изменит как-то этот gunicorn?)))

и определись, дурень, 1) где ты хранишь данные - в памяти программы или «во фласке». 2) ты хочешь раздельные процессы для скорости и надежности, НО ПРИ ЭТОМ жалуешься, что нельзя шарить данные, причем это «во фласке нельзя». голову-то включи немного

азы освой сначала, редис блин.

не знаю, что такое gunicorn, с фласком тоже не работал.

Спасибо, слушать оскорбления от человека, который говорит о том, о чём впервые слышит, нет желания.

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

процессы? так они и не могут шарить данные

да ты шо

а в конце не нужен слэш в имени модуля?

человека, который говорит о том, о чём впервые слышит

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

Почему ты так обосрался? Потому что ты безмозглый хомячок который кроме простых ответов ничго не понимает, улавливает только массовый бред таких же хомяков, берет нечто, не понимает как работает, городит бредовые костыли.

Я-то описаную тобой задачу решил (сначала даже не зная особенно питона) и не раз, она решается за 5 (пять) минут спокойно, без лишних телодвижений. А ты нет, ты даже потратил время, «городил редис», но т.к. ты хомячок ничего не получилось. Вот и вся разница. И ты мне говоришь «говорит о том, о чём впервые слышит»?

Гораздо лучше тебя понимаю, о чем говорю, в том-то дело. И бредовых утверждений вроде «во фласке нельзя хранить шарящиеся данные» не высказываю.

Кроме того, если хомячок-недоумок вроде тебя кроме фласка ни о чем не слышал, то и с фласком это сделать тоже скорее всего можно (мне просто не было нужно). Но решение я тебе не подскажу из принципа. Вот из принципа. Вот просто не хочу таким как ты помогать - тупым и наглым. Мучайся дальше.

У меня не одно такое приложение работает, шарит стейт, доступ синхронизирован, всё отлажено и работает.

Уважаемый, у меня тоже, я знаю как это делается.

гуникорн и фласк про который ты ничего не понимаешь и которые тебе не помогли

тут не спорю, просто посмотрел на один из самых «на слуху» веб-фреймворков.

в итоге ты заключил, что в рамках питона эта задача не решается

ничего подобного я не говорил. Мне нравится писать на python-е, довольно приятный язык, не смотря на свои особенности.

Решения от вас я не просил. На грубость, наглость и провокации отвечать не буду.

В каком из случаев? в import? там слэши не нужны

Царь пышки? Перспективный поциент кмк.

Ты задачку-то решил?

Нет конечно же, а ты думал я правда интересуюсь растом? Охохо!