EDP, PHP, Python и все-все-все

На неделе Rails 3 в бете будет. Хватит дурковать.

зовис, зачем веб-фреймворкам событийная модель?

зовис, зачем веб-фреймворкам событийная модель?

какие варианты предлагаешь при ~100000 конектов ?

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

Вот тру евентед фреймворк на тру языке http://github.com/rklophaus/nitrogen

>> зовис, зачем веб-фреймворкам событийная модель?

какие варианты предлагаешь при ~100000 конектов ?

Кластер.

В том смысле что ты думаешь нет. И не нужно.

Цитируем ZveN

Вот тру евентед фреймворк на тру языке http://github.com/rklophaus/nitrogen

+2048^2

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

> нитроген лучше джанги?

Для прокачки ЧСВ - гораздо лучше.

>Для прокачки ЧСВ - гораздо лучше.

хм,спасибо

Джангу не смотрел, но нитроген прост и понятен: логика обычно отделена от верстки. Да и эрланг, ИМХО, скорострельнее питона + масштабируется легко, на роутере можно поднять. Из минусов - под эрланг может быть дефицит энтерпрайза: всяких там xml-парсеров (если вдруг надо), переходников к ораклам и проч.

а с документацией у нитрогена как?

Меня вот бесит в эрланге отсутствие штуки aka rubygems, унифицированного API для доступа к базам данных (не odbc), повсеместное использование префиксов к модулям, вместо того чтобы юзать packages. Но больше всего достает отладка путем io:format, потому что хрен поймешь где и что вывалилось.

> на роутере можно поднять

%)

> а с документацией у нитрогена как?

API и сэмплы на сайте хорошо описаны. Но часть док прямо в сорцах: в комментах нужно смотреть, хотя сложности это сейчас не вызывает. Пока в сорцы нитрогена лазил только за описаловом к wf:email и http_basic_auth.

ясно, спасибо!

> rubygems

faxien. erlware project

> унифицированного API для доступа к базам данных (не odbc),

Касался когда-то с голым jdbc - профита не прочувствовал. Имеется ввиду что-то типа хибернейта?

Кластер.

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

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

Event-driven - это значит, что оно не использует нити и тоже будет грузить только одно ядро // К.О.

Вот тру евентед фреймворк на тру языке http://github.com/rklophaus/nitrogen

я не знаю erlang и не стану использовать то, чего не знаю

Event-driven - это значит, что оно не использует нити и тоже будет грузить только одно ядро // К.О.

сейчас оно вообще ничего не использует

>> Event-driven - это значит, что оно не использует нити и тоже будет грузить только одно ядро // К.О.

сейчас оно вообще ничего не использует

Это значит, что в чем бы не была проблема, EDP ее не решит.

Это значит, что в чем бы не была проблема, EDP ее не решит.

если попробовать распараллелить ее ? EDP будет обрабатывать 3-4 события выделяя их в разные потоки ?

> EDP будет обрабатывать 3-4 события выделяя их в разные потоки ?

Весь пойнт EDP - избежать использования нитей, как раз для ситуаций, когда у тебя 100500 слиентов, и создавать по нити на каждого невозможно. Можно ли как-то задействовать гибридную схему (пул нитей + event-driven в пределах нити) - ХЗ.

> Можно ли на PHP использовать СОП ?

Таки пых-пых вообще использовать можно? А я думал, что можно только Джаву использовать и быть не Ъ.

>если попробовать распараллелить ее ? EDP будет обрабатывать 3-4 события выделяя их в разные потоки ?

таки если паралеллить, то в процессы же, а не в нити.

А PEP 342 не поможет? Там допилили генераторы до чего-то похожего на корутины. Там и примеры шедулеров есть, и send в них можно делать, ну почти агенты же, или я неправильно понимаю?

для Ъ

Coroutines are a natural way of expressing many algorithms, such as
simulations, games, asynchronous I/O, and other forms of event-
driven programming or co-operative multitasking. Python's generator
functions are almost coroutines — but not quite — in that they
allow pausing execution to produce a value, but do not provide for
values or exceptions to be passed in when execution resumes. They
also do not allow execution to be paused within the «try» portion of
try/finally blocks, and therefore make it difficult for an aborted
coroutine to clean up after itself.

<skipped for good>

In other words, with a few relatively minor enhancements to the
language and to the implementation of the generator-iterator type,
Python will be able to support performing asynchronous operations
without needing to write the entire application as a series of
callbacks, and without requiring the use of resource-intensive threads
for programs that need hundreds or even thousands of co-operatively
multitasking pseudothreads. Thus, these enhancements will give
standard Python many of the benefits of the Stackless Python fork,
without requiring any significant modification to the CPython core
or its APIs. In addition, these enhancements should be readily
implementable by any Python implementation (such as Jython) that
already supports generators.

А PEP 342 не поможет? Там допилили генераторы до чего-то похожего на корутины. Там и примеры шедулеров есть, и send в них можно делать, ну почти агенты же, или я неправильно понимаю?

ну я пока попробую перевести с epoll на kqueue и запустить все это на FreeBSD, а потом уже о python подумаю :)

>ну я пока попробую перевести с epoll на kqueue и запустить все это на FreeBSD, а потом уже о python подумаю :)

гхм. так ведь вроде бы тот же twisted поддерживает через libevent и epoll, и kqueue.

> Там допилили генераторы до чего-то похожего на корутины. Там и примеры шедулеров есть, и send в них можно делать

Вместо использования писанных на коленке лучше погуглите на предмет гринлетов в питоне, ну и stackless никто не отменял.

>Вместо использования писанных на коленке лучше погуглите на предмет гринлетов в питоне, ну и stackless никто не отменял.

Так вроде бы ж сам Гвидо писал, а мы все знаем что Гвидо велик ;) Просто эта штука походу изкоробки должна работать на всех реализациях, раз уж часть языка, и может пригодиться если надо построить что-нибудь pure-python.

Про отличия от генераторов написано вкратце на хоумпаге greenlets, а можно еще чего-нибудь почитать про наколеночность текущих генераторов?

Я имел в виду, что вместо примера из PEP лучше использовать сторонние библиотеки (которые все равно через генераторы, но зато более функциональные и зрелые).

Конечно, по сравнению, например, с корутинами Lua питоновские генераторы слабенькие, но в остальном вполне годные.

Пруф можно, а что-то найти не могу.

Ни одной нужной мне либы я не нашел упакованой этими тулзами => их не сущестует.