Здравствуйте, eao197, Вы писали:
E>Здравствуйте, WolfHound, Вы писали:
WH>>А как там у нас с использованием оберона в распределенке? Или даже на многопроцессорных машинах? Ведь один ГЦ на всех это не эффективно даже для многопроцессорных систем, а в распределенке он вобще не живет (вернее завести можно но это будет мегатормоз).
E>Кстати, а у кого с этим нет проблем?
У тех, кто на это забивает
Я имею в виду Эрланг, кде нет общей памяти между процессами (причём как в пределах одного рантайма так и в распределённой системе)
Хотя это чревато в ситуациях, когда нужно именно большие куски "шарить" или передавать.
Здравствуйте, eao197, Вы писали:
WH>>А как там у нас с использованием оберона в распределенке? Или даже на многопроцессорных машинах? Ведь один ГЦ на всех это не эффективно даже для многопроцессорных систем, а в распределенке он вобще не живет (вернее завести можно но это будет мегатормоз). E>Кстати, а у кого с этим нет проблем?
У тогоже ерланга.
SObjectizer тоже шаг в правильном направлении но вы кудато не туда свернули... broadcast это камень на шее.
ИМХО наиболие верное направление это сигулярити со своими полностью изолированными процессами и каналами у которых описан протокол общения.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>>>А как там у нас с использованием оберона в распределенке? Или даже на многопроцессорных машинах? Ведь один ГЦ на всех это не эффективно даже для многопроцессорных систем, а в распределенке он вобще не живет (вернее завести можно но это будет мегатормоз). E>>Кстати, а у кого с этим нет проблем? WH>У тогоже ерланга.
Имхо, если делать распределенное приложение на Oberon, где процессы просто обмениваются между собой сообщениями, то получится то же самое. Вот интересно, не изменяет ли мне память, но Сергей Губанов когда-то о чем-то подобном говорил.
WH>SObjectizer тоже шаг в правильном направлении но вы кудато не туда свернули... broadcast это камень на шее.
А подробнее тему раскрыть можно? Буду очень признателен. Или здесь, или в приват по почте, или на SourceForge-вский форум.
Буду очень-очень признателен
WH>ИМХО наиболие верное направление это сигулярити со своими полностью изолированными процессами и каналами у которых описан протокол общения.
AFAIK, в Minix3 это уже работает (только без жесткой спецификации протоколов).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
AVC>>Из компонентности логически вытекают частные следствия, такие как необходимость типо-безопасности и сборки мусора.
VD>Не-а. Не вытикают. Примеры? Их есть у меня... COM! И этим все сказано. В нем нет ни сборки мусора, ни безопасности. Но он является одной из первый промышленных компонентных систем.
А почему это в COM нет типобезопасности??
Да и сборка мусора — для компонентной системы важно скорее наличие управления временем жизни обьектов, а не конкретный алгоритм. Худо-бедно reference counting c этим справляется.
Да, мы ещё Corba забыли — там примерно то же самое...
Здравствуйте, WolfHound, Вы писали:
WH>SObjectizer тоже шаг в правильном направлении но вы кудато не туда свернули... broadcast это камень на шее. WH>ИМХО наиболие верное направление это сигулярити со своими полностью изолированными процессами и каналами у которых описан протокол общения.
Насколько я понимаю, из языков обероновского семейства Zonnon вводит параллелизм на основе активных объектов и синтаксически управляемых диалогов (протокол задается в виде EBNF).
Это то, что имеется в виду (примерно)?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Дарней, Вы писали:
Д>Это просто частное определение. На самом деле компонентность как таковая никак не связана с объектами.
Может быть, ты не заметил — я все время говорю о компонентно-ориентированном программировании (КОП) а не о "компонентности как таковой".
AVC>>Слушай, Objective C составлен из языков Си и Смоллток. AVC>>Ни тот, ни другой не являются языками КОП. AVC>>Почему же Objective C вдруг стал? AVC>>За счет чего?
Д>В той ссылке, которую привел ты сам, именно он приводится как пример первой реализации компонентности в ООП языке.
Обычно говорится об удачной метафоре Бреда Кокса — "software ICs".
Что касается практического воплощения — объектная модель без сборки мусора не годится на роль компонентной.
А сборка мусора требует (в императивном языке) определенной перестройки системы типов.
Такая перестройка была в Обероне, и ее не было в Objective C, гибриде Си и Смоллтока.
(В этом смысле я и назвал Objective C смесью бульдога с носорогом; уж больно эти два языка разные.)
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>Насколько я понимаю, из языков обероновского семейства Zonnon вводит параллелизм на основе активных объектов и синтаксически управляемых диалогов (протокол задается в виде EBNF). AVC>Это то, что имеется в виду (примерно)?
Это совсем не то.
1) Активные объекты всеравно плавают в одном объектоном пространстве. Те нужен глобальный ГЦ, а это плохо.
2) Вешать протокол на объект это ересь. При таком подходе совершенно не ясно как будет происходить общение между несколькими объектами.
3) EBNF это полнейший оверкилл. В общем случае эффективно реализовать контроль контекстно независимой грамматики невозможно. Нужно делать какоето подмножество типа LL(1). Но даже для такой ущербной штуки понадобятся стеки и тп... И это при том что на практике ничего большего чем конечный автомат не нужно.
Короче читайте про сингулярити. Конечно виртуальная машина у них посредственная но модель процессов и каналов у них ИМХО очень правильная.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, eao197, Вы писали:
E>Имхо, если делать распределенное приложение на Oberon, где процессы просто обмениваются между собой сообщениями, то получится то же самое. Вот интересно, не изменяет ли мне память, но Сергей Губанов когда-то о чем-то подобном говорил.
Точно также оно делается на всяких сих и тп. Модель оберона тут совершенно не помогает.
E>А подробнее тему раскрыть можно? Буду очень признателен. Или здесь, или в приват по почте, или на SourceForge-вский форум. E>Буду очень-очень признателен
Лично мне нужно очень много мелких процессов порядка нескольких тысяч на одной машине которые стоят в кластере состоящим из десятков машин.
broadcast в таких условиях это кирдык всему. Болие того даже поддержка модели в которой в принципе возможен broadcast ничего хорошего не даст.
Также мне очень важно знать что процесс с которым идет общение умер. Это нужно для убивания зомбей (процессы которые уже не смогут завершить свою работу ибо партнеры подохли) чтобы память не жрали.
Еще нужна возможность прокачки большого потока данных с некоторой обработкой не поднимая их все в память.
Короче модель сингулярити очень близка к тому что мне надо.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > Лично мне нужно очень много мелких процессов порядка нескольких тысяч на > одной машине которые стоят в кластере состоящим из десятков машин.
Вот один процесс захочет послать 10000 сообщений другим процессам — и
тоже кирдык будет, так как каналы будут забиты 10000ми одинаковых сообщений.
Здравствуйте, Cyberax, Вы писали:
C>Вот один процесс захочет послать 10000 сообщений другим процессам — и C>тоже кирдык будет, так как каналы будут забиты 10000ми одинаковых сообщений.
Что-то я не вижу реальной необходимости в таких фичах.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Лично мне нужно очень много мелких процессов порядка нескольких тысяч на одной машине которые стоят в кластере состоящим из десятков машин. WH>broadcast в таких условиях это кирдык всему. Болие того даже поддержка модели в которой в принципе возможен broadcast ничего хорошего не даст. WH>Также мне очень важно знать что процесс с которым идет общение умер. Это нужно для убивания зомбей (процессы которые уже не смогут завершить свою работу ибо партнеры подохли) чтобы память не жрали.
В SObjectizer естественным образом поддерживается peer-to-peer взаимодействие, сообщение идет именно в тот канал, в который отсылалось.
Умершие процессы так же определяются путем контроля отсутствия активности в канале даже после принудительного пингования -- канал разрывается в этом случае.
WH>Еще нужна возможность прокачки большого потока данных с некоторой обработкой не поднимая их все в память.
Т.е. пересылка из одного канала в другой по мере получения очередной порции?
Не вижу проблем -- прочитал за один раз из одного канала 10K, обработал, записал в другой канал.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, WolfHound, Вы писали:
WH>Лично мне нужно очень много мелких процессов порядка нескольких тысяч на одной машине которые стоят в кластере состоящим из десятков машин.
Кстати, а топология их соединений какая?
И в какой момент процесс узнает, с кем именно он должен быть соединен?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>В SObjectizer естественным образом поддерживается peer-to-peer взаимодействие, сообщение идет именно в тот канал, в который отсылалось.
Если я правильно понял то что написано в твоей статье сообщения отсылаются не в канал, а агенту?
E>Умершие процессы так же определяются путем контроля отсутствия активности в канале даже после принудительного пингования -- канал разрывается в этом случае.
Заниматься пингованием в прикладном коде идея крайне не удачная.
Физический хост умерает черизвычайно редко. Как правило обработка прекращается когда один из процессов понимает что дальше обрабатывать не имеет смысла.
E>Т.е. пересылка из одного канала в другой по мере получения очередной порции? E>Не вижу проблем -- прочитал за один раз из одного канала 10K, обработал, записал в другой канал.
Именно так. Только мне нужно в одном логическом канале иметь несколько потоков которые могут идти как в одну так и в другую сторону. Также мне нужно уметь пропускать несколько логических каналов по одному физическому.
Причем все это должно быть абсолютно прозрачно для прикладного кода иначе вся эта система не имеет смысла.
E>Кстати, а топология их соединений какая?
Есть несколько типов компов со своими специфическими ресурсами. Ну и соответственно обработка разных частей запроса происходит на разных компах.
Короче работают изолированные друг от друга группы процессов.
E>И в какой момент процесс узнает, с кем именно он должен быть соединен?
Процесс это некий активный объект который при создании получает на вход какието параметры среди которых могут быть end-point'ы каналов.
Так же ендпоинты могут передаватся через каналы.
Но сейчас это все не реализованно и для комуникаций используется жуткий зоопарк из всяких корб все это жутко не удобно.
По этому и пишу эту систему.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Вертер, Вы писали:
В>а чем так плоха зависимость? В>Ведь необходимость в написании программ — это не процесс, а результат. Создают программы для решения проблем...
Почитай по антипаттерн Vendor lock-in: здесь и здесь.
АХ>>Ну и понятно, что так как Линукс распространяется с исходными кодами, его проще заточить под свои нужды.
В>что-то не понял как из первого вытекает второе.
Если ты хочешь, например, создать новую железку (какой-нибудь наладонник или еще чего), то ты можешь в качестве ОС взять Линукс и модифицировать ядро под специфику железа.
Значительно проще чем изобретать велосипед, разрабатывая свою ОС.
Ну и например, если ты в ядре обнаружил баг, его проще поправить.
В случае Windows баг вообще трудно диагностировать, а уж поправят его вообще хрен знает когда (если он не критичен по безопасности).
Здравствуйте, Mamut, Вы писали:
PD>>>И дети их в Линуксовые игры играют ? Сомневаюсь... АХ>>Дети их играют в PlayStation. А PlayStation 3 будет с Linuxом.
M>Он не будет с Линухом. Сони выпустит Линух для Playstation. А это — две большие разницы. Просто для предыдущих Сони в качестве эксперимента выпускала Линукс. Для третьей Сони тоже выпустит — это просто своего рода тоже PR
Нет.
Linux will be pre-installed on the PS3 hard drive.
Because we have plans for having Linux on board the PS3, we also recognize Linux programming activities… Other than game studios tied to official developer licenses, we'd like to see various individuals participate in content creation for the PS3.
Izumi Kawanishi on the presence of the Linux in the PS3.
Здравствуйте, FR, Вы писали:
AVC>>Слушай, Objective C составлен из языков Си и Смоллток. AVC>>Ни тот, ни другой не являются языками КОП.
FR>Интересно что именно мешает Смаллталку быть компонетно-ореинтированным?
А в каком виде там могут распространяться компоненты?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, WolfHound, Вы писали:
WH>3) EBNF это полнейший оверкилл. В общем случае эффективно реализовать контроль контекстно независимой грамматики невозможно. Нужно делать какоето подмножество типа LL(1). Но даже для такой ущербной штуки понадобятся стеки и тп... И это при том что на практике ничего большего чем конечный автомат не нужно.
Я здесь немного не понял.
Любой регулярный язык может быть выражен с помощью EBNF.
Если же в языке есть рекурсия (он не регулярный), то как обойтись без стека?
Вообще, почему ты так раскритиковал EBNF?
Ведь EBNF — это расширенная BNF, т.е. EBNF = BNF + циклы + опции.
Т.е. EBNF, по идее, как минимум не уступает по мощности BNF.
Приверженность Вирта к языкам программирования с LL(1)-грамматикамми (чтобы код был читабельным) никак не связана с мощностью EBNF.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>Такая перестройка была в Обероне, и ее не было в Objective C, гибриде Си и Смоллтока.
знаешь, в чем твоя проблема? Ты просто уже решил априори, что единственно верная реализация КОП — это та, которая была в обероне.
Ответь на один простой вопрос. Какой аргумент сможет тебя убедить, что оберон не имеет никакого отношения к появлению явы?
Здравствуйте, AVC, Вы писали:
AVC>Ведь EBNF — это расширенная BNF, т.е. EBNF = BNF + циклы + опции. AVC>Т.е. EBNF, по идее, как минимум не уступает по мощности BNF.
EBNF — это BNF с некоторым синтаксическим сахаром. По мощности они совершенно эквивалентны, т.е. всегда возможно не меняющее семантики преобразование из одного в другой.
Здравствуйте, WolfHound, Вы писали:
E>>В SObjectizer естественным образом поддерживается peer-to-peer взаимодействие, сообщение идет именно в тот канал, в который отсылалось. WH>Если я правильно понял то что написано в твоей статье сообщения отсылаются не в канал, а агенту?
Это внутри одного процесса.
Если же организуется распределенное приложение из нескольких процессов, то все они должны быть соеденены коммуникационными каналами. Например, если есть одни центральный процесс, который открывает серверный сокет и N клиентов, которые должны подключаться к нему через клиентские сокеты, то центральное приложение создает у себя серверного транспортного агента, а клиенты -- по одному клиентскому транспортному агенту. Эти агенты будут отвечать за установку соединений и организацию коммуникационных каналов.
Если же есть N процессов, которые открывают серверные сокеты и один клиент, который должен одновременно к ним подключиться, то серверные процессы создают у себя по одному серверному транспортному агенту, а клиентский процесс должен создать N клиентских транспортных агентов.
Об организации транспортных агентов, которые поддерживают выбранную разработчиком топологию, отвечает сам разработчик. Но, когда соединения уже установлены, каждое соединение рассматривается SObjectizer-ов в качестве коммуникационного канала. И при отсылки сообщения посредством send_msg можно указать, в какой именно канал должно уйти сообщение. Поэтому, если клиент подключен к N серверам, то он легко может общаться только с одним из серверов, если будет посылать сообщения в канал данного сервера.
E>>Умершие процессы так же определяются путем контроля отсутствия активности в канале даже после принудительного пингования -- канал разрывается в этом случае. WH>Заниматься пингованием в прикладном коде идея крайне не удачная.
+1
Поэтому пингование выполняет сам SObjectizer на уровне своего транспортного протокола.
WH>Физический хост умерает черизвычайно редко. Как правило обработка прекращается когда один из процессов понимает что дальше обрабатывать не имеет смысла.
Если процесс завершается корректно и корректно закрывает свои каналы, то удаленная сторона это сразу же обнаруживает и считает канал закрытым, о чем SObjectizer информирует прикладной код посредством сообщения msg_client_disconnected.
E>>Т.е. пересылка из одного канала в другой по мере получения очередной порции? E>>Не вижу проблем -- прочитал за один раз из одного канала 10K, обработал, записал в другой канал. WH>Именно так. Только мне нужно в одном логическом канале иметь несколько потоков которые могут идти как в одну так и в другую сторону. Также мне нужно уметь пропускать несколько логических каналов по одному физическому. WH>Причем все это должно быть абсолютно прозрачно для прикладного кода иначе вся эта система не имеет смысла.
В SObjectizer это можно сделать на уровне SOP-каналов (т.е. те, которые передают сообщения агентов, есть еще raw-каналы, которы используются для сырых, бинарных данных). Например, для каждого логического потока используются свои сообщения. Скажем a_first_logical_t::msg_receive_data, a_second_logical_t::msg_send_data, a_third_logical_t::msg_data. Либо можно использовать одно и тоже сообщение, но в самом сообщении указывать, к какому логическому потоку данные относятся.
Однако, при использовании SOP требуется, чтобы поток дробился на одельные сообщения на прикладном уровне, поскольку SObjectizer сначала закачивает все сообщение в память и только потом доставляет его обрабатывающему агенту. Поэтому, если весь поток будет представлен одим сообщением, то сам понимаешь. А вот если поток разбивается на серию сообщений, то каждое сообщение может обрабатываться по мере поступления.
E>>И в какой момент процесс узнает, с кем именно он должен быть соединен? WH>Процесс это некий активный объект который при создании получает на вход какието параметры среди которых могут быть end-point'ы каналов.
У нас сейчас аналогичная ситуация -- процесс получает описания каналов через конфигурацию. Например, вот здесь описывается, как процесс может создавать нужные ему транспортные агенты через подсистему so_sysconf.
WH>Так же ендпоинты могут передаватся через каналы.
Так же нет проблем, транспортные агенты могут создаваться и уничтожаться в динамике.
WH>Но сейчас это все не реализованно и для комуникаций используется жуткий зоопарк из всяких корб все это жутко не удобно. WH>По этому и пишу эту систему.
Интересная задачка. Желаю удачи!
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
тоже шаг в правильном направлении но вы кудато не туда свернули... broadcast это камень на шее.
