ZZZ
чтобы он не делал херни и запилил отдельный сервис, обслуживающий эти данные

Тоесть по вашему допиливать дополнительный сервис - не херня?
А отдавать он эти данные кудою будет остальным модулям? Сокеты? Вы не заметили что скорость обмена с ОЗУ напрямую в сотни раз проще и быстрее? БД? В тысячи раз медленнее чем ОЗУ. А синхронизация? Откуда остальные модули узнают что мой “сервис” изменил данные “х”? Или приклеим этому сервису ещё один сервис, который через вспомогательный сервис будет рассылать уведомления? Очень “надёжно”
В случае с несколькими процессами подход с SharedMemory намного лучше чем хранить общие данные в БД, к которым нужен моментальный доступ с синхронизацией. Поэтому вы совсем неоправданно так возвышаете себя перед своим знакомым.

JOHN_16
мм а БД в ОЗУ не подойдут? Из реляционных SQLite умеет так

Если мы данные получаем из другого процесса, уже особо не важно где конкретно они хранятся. Обмен в 99% случаев идёт через механизмы, которые в тысячи раз медленнее доступа к ОЗУ. К тому же получаем дополнительный гемор с синхронизацией.

JOHN_16
Если вы прям так хотите обойти GIL, то для это воспользуйтесь распределением за счет процессов, делается это модулем multiprocessing, в доках и примеры передачи между процессами объектов.

Вооот. Это уже ближе к истине. Может есть ссылка?
Спасибо.

ZZZ
Не распыляйся. Прочитал весь топик и понял, что комрад xneo с вебом знаком на уровне скачивания порнороликов. Может он и хороший программист, вот только на веб он ничего еще в жизни не писал Забей болт, мой тебе совет.

xneo
В случае с несколькими процессами подход с SharedMemory намного лучше чем хранить общие данные в БД, к которым нужен моментальный доступ с синхронизацией.

Маленький вопрос. А как вы при асинхронном исполнении собираетесь обеспечивать согласованность данных? Все равно потребуются локи семафоры или посылка сообщений. Когда вы все это сделаете, то обнаружите что повторили ZeroMQ или Redis, причем в 10 раз хуже чем то что уже до вас сделано.

xneo
Обмен в 99% случаев идёт через механизмы которые в тысячи раз медленнее доступа к ОЗУ

Практически все БД могут использовать SharedMemory, и не ограничены передачей через сокеты, как вы наивно полагаете.

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

doza_and, Ну коднееечно же. Если мой софт разделён на несколько кластеров тогда да.
А теперь вопрос:
Вот не надо мне 10 серверов. Мне хватает с головой одного. Допускаете такой вариант?
Зачем мне все эти костыли если софт работает на одном физическом сервере? Вникаете понемногу?

Ща гляну, вроде ж ветку не переименовали в “философия на тему необходимости использования ZeroMQ”?
Мы говорим о GIL ещё?
У меня один сервер, на нём один модуль/процесс. Это такое условие. Так построена задача.
Питон поддерживает многопоточность? Да.
Могу я создать 100500 потоков и использовать всю мощность CPU? Нет.
Вот в этом вся суть вопроса. Если я ошибаюсь и питон (именно CPython) каким-то образом всё же может использовать в одном процессе весь CPU, покажите где я ошибаюсь.

4kpt_III
Может он и хороший программист, вот только на веб он ничего еще в жизни не писал

Вы упустили мой вопрос в начале дискуссии. При чём тут веб вообще?

Вместо тысячи слов

xneo
Существуют ли WEB-фреймворки с модулями написаными на С, которые могут при полной загрузке использовать, скажем, 4-ядерный CPU на 100%?

Ага. Видел. Отвечаю. Это и не нужно И Вам уже так ответили…

4kpt_III, а разве я спрашивал что мне нужно? Я задал чёткий вопрос.
Ответ да, существуют или нет, не существуют.

xneo
нет, не существует, потому что GIL.
Вне одного процесса - модуль multiprocessing

xneo
Я вас понял, но думаю что вы слишком зациклились на конкретном и не самом лучшем решении. Но это ваше дело. А как звучит ваша задание? Какие задачи нужно решить? что понадобился именно такой подход

JOHN_16
Пока что нету каких-то конкретных больших задач. Зацепился за питон, когда увидел как его применяют для программирования встраиваемых систем (Raspberry PI, BeagleBone). Очень понравилась простота разработки.

Из личного опыта на питоне пока только небольшой сенсор для IPChecker и демон для биллинга под Linux(в процессе).