фоновые процессы в вебприложениях

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

http://celeryproject.org/ Подобие крона там тоже есть, называется celerybeat.

Копните в сторону связки Celery+RabbitMQ. Меня, в свое время, здорово впечатлило.

Celery? RabbitMQ? Песец. Чем не устроил обычный XML-RPC, <любойдругойRPC>, даже обычный HTTP?

Т.е. с идеей гонять модель отдельным процессом всё ок?

Т.е. с идеей гонять модель отдельным процессом всё ок?

Можешь смело плевать в сторону сельдерейщиков.

Да чёрт бы с ним с Celery, меня сейчас не конкретные инструменты интересуют. Нет понимания что и с чем должно взаимодействовать.

С целери реально закодить быстрее, чем реализовыать свой РПЦ. Плюс распределенность из коробки. Мне нравится.

Т.е. с идеей гонять модель отдельным процессом всё ок?

В общем, да. Если архитектура предусматривает постоянное моделирование состояния мира^Wсущности, то реализация этого моделирования в отдельном процессе и периодическое обращение к этому процессу веб-сервера (за данными о текущем состоянии сущности) - вполне нормальное решение.

Нет понимания что и с чем должно взаимодействовать.

Очевидно, что нужен сервер, считающий модель/реагирующий на события и к нему морда (веб), которая может считывать состояние и посылать события.

// Как хреново быть в шкуре кэпа.

С целери реально закодить быстрее, чем реализовыать свой РПЦ

реализовыать свой РПЦ

WAT. Кто говорит о «своем RPC»? RPC для Python уже дофига: http://stackoverflow.com/questions/1879971/what-is-the-current-choice-for-doi...

Более того - ты не обязан использовать RPC.

Плюс распределенность из коробки

Что ты имеешь в виду? Любой RPC в некотором смысле «распределенный».

С целери реально закодить быстрее, чем реализовыать свой РПЦ

Когда это «an asynchronous task queue/job queue based on distributed message passing» успело стать RPC?

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

RPC для Python уже дофига:

Я знаю, некоторые из тех библиотек приходилось использовать на практике. Celery субъективно больше всего понравилась.

Что ты имеешь в виду? Любой RPC в некотором смысле «распределенный».

Имею в виду диспетчеризацию заданий по нодам.

Спорить не буду, РПЦ для задачи ТС вполне может подойти, а целери может оказаться оверкиллом.

Имею в виду диспетчеризацию заданий по нодам.

Ну, моделировать состояние сущности на нескольких узлах - это точно не нужно ТС. По крайней мере, пока.

Есть подозрение, что можно обойтись определением и записью состояния при запросах это состояние изменяющих

Даже если это будут делать одновременно несколько процессов?

БД умеет атомарную запись состояния, чем такой вариант будет отличаться от двух одновременных запросов к рпц?

БД умеет атомарную запись состояния, чем такой вариант будет отличаться от двух одновременных запросов к рпц?

В сервере можно вообще на гонки и синхронизацию забить.

Поясните для тупых.

Можно обрабатывать запросы в один поток, же.

начни со скрипта sostoyaniye.php нутыпонял

twisted

это точно не нужно ТС.

категоричненько :)

ТС еще не понимает, нужен ли ему отдельный процесс вообще.

Отдельный процесс, адназзначна!
И соединяйся с ним с помощью какого-нибудь стандартного HighLevel IPC протокола. MQ-библиотеки, twisted и прочее это LowLevel IPC. Они обеспечивают только базисный уровень взаимодействия. А HighLevel (SOAP,XML-RPC,etc...) позволяют тебе абстрагироваться от транспорта и думать сразу в терминах прикладной логики.

делал такое на perl (Mojolicious).

Суть: делается глобальный (статичный) хеш переменных состояний, запускается отдельный поток (реактор), который крутится и свое состояние сохраняет в статичный хеш в переменные. А из браузера по таймауту аяксом дергается урл, который просто возвращает этот хеш в виде json/xml ответа. На клиенте же - как хочешь, так и рисуешь состояние.