Ответ на »сообщение 4824« (FR)
___________________________

К (www.kx.com)

Ответ на »сообщение 4854« (Стэн)
___________________________

Ответ на »сообщение 4853« (Илья Ермаков)
___________________________
Когда происходит возврат из этого обработчика – всё падает. И организация этих событий в виде сообщений, составленных в очередь, а не как в Delphi прямым вызовом, есть решение этой проблемы
Что, собственно говоря, и есть в ГУИ Блэкбокса. Generic Message Bug - и проблем не знаем :-)

Ответ на »сообщение 4853« (Илья Ермаков)
___________________________
>>> Уже в 80-м году в Аде ввели прекрасные абстракции... Однако они не привычны для низкоуровневщиков, слишком абстрактны - "какие-то рандеву, какие-то ожидания, какие-то задачные типы... Где любимый CreateThread и EnterCS?".

Я думаю, что ответ здесь лежит на поверхности. Ада нужна была DoD’у для написания необходимых им приложений. А необходимость-то у них какая? Сбор и анализ информации из множества источников, координация боевых единиц, распределенных в пространстве. Им сам Бог велел так поступить…
А любимые «CreateThread и EnterCS» – это ведь Unix/Windows. До недавнего времени у всех был одноядерный процессор и даже с сетью работали совсем не много. Два потока не будут работать быстрее, чем одни, на таком процессоре и блокирующих операций в программах особо не было. Тот же Страуструп в своей книге «Дизайн и эволюция», когда описывает, как он создавал C++, только и пишет: «Производительность, производительность, производительность…» Зачем кому-то нужны были такие абстракции, если они по определению будут работать медленнее имеющихся альтернатив?

>>> Параллельность - это уже давно ставшее типовой потребность.

А вот здесь необходимо указать предметную область, в которой она стала давно, потому как далеко не везде это так. Та же  разработка GUI-приложений в секторе ERP. Там не параллельность в первую очередь важна, а избавление от Inversion of Control (IoC) которая есть в Delphi, C# и, насколько я знаю, в Java.
Сколько раз сталкивался. Есть компонент с событием (Delphi). Прикладной программист пишет реализацию обработчика этого события и в ней меняет состояние формы (в частности внешний вид) и компонент удаляется. Когда происходит возврат из этого обработчика – всё падает. И организация этих событий в виде сообщений, составленных в очередь, а не как в Delphi прямым вызовом, есть решение этой проблемы. Здесь параллельность – бесплатный бонус, а не цель.

Ответ на »сообщение 4852« (Стэн)
___________________________

Ответ на »сообщение 4851« (Илья Ермаков)
___________________________
А что такое стандартное решение? То, что встроено в язык? Но ведь в каждой предметной области свои стандартные решения! И если все их встраивать в язык, то получится язык-монстр. И это с одной стороны, а с другой – сразу же всё не встроишь, каждый день появляются новые потребности,

Параллельность - это уже давно ставшее типовой потребность. И абстракции для нее прекрасно и давно проработаны. Можно спокойно вводить минимум таких ортогональных абстракций в язык. Увы, у очень многих рабочие абстракции - это тред и критическая секция... уровень "ассемблера параллельности".
Уже в 80-м году в Аде ввели прекрасные абстракции... Однако они не привычны для низкоуровневщиков, слишком абстрактны - "какие-то рандеву, какие-то ожидания, какие-то задачные типы... Где любимый CreateThread и EnterCS?".

Ответ на »сообщение 4851« (Илья Ермаков)
___________________________
>>> Да, взглянул на Вашу реплику с другой стороны. Ведь Вы как раз и занимаетесь тем, что реализуете библиотеку для поддержки высокоуровневых параллельных абстракций. На С++. Что доказывает, что готовых-то решений у Вас нет :-)

Да, действительно, нет. Но сверху-то нам ничего не дается. В Обероне Вы что-то делаете, а здесь я, коль Страуструп в свое время не сделал… ;-)
На самом деле ситуация достаточно проста. Есть проверенный временем язык. Его минусы известны, но у него куча стандартных библиотек, и до сих пор многие на нем пишут. Я сам использую при необходимости. И есть класс задач, где нужна параллельность. Из чисто коммерческих соображений переходить на другой язык не резон, а возможность описывать параллельность более естественно была бы весьма кстати.
Тем более что это не просто реализация. Это модель, позволяющая добавить поддержку актеров в уже существующие языки. На C# её можно будет реализовать и должно быть лучше чем в С++, так как есть сборка мусора и метаинформация несравненно более детальна.

>>> Вот Вам и отличие - Вы своими ногами идете обероновским путем, потому что стандартных решений ваш инструментарий не дает :-)

А что такое стандартное решение? То, что встроено в язык? Но ведь в каждой предметной области свои стандартные решения! И если все их встраивать в язык, то получится язык-монстр. И это с одной стороны, а с другой – сразу же всё не встроишь, каждый день появляются новые потребности, и ждать пока разработчики компилятора их переварят и добавят поддержку, нет ни какой возможности. И мой инструмент дает мне важную вещь: возможность реализовать то, что мне нужно самому. Хотя, C++ есть C++. В этом смысле он далеко не идеален…

>>> Вопрос не в том "что не позволяет", а какой ценой и кровью... А как быть с компонентной средой? Если язык не поддерживает напрямую абстракций с жестким контролем компилятором и рантаймом, то как быть уверенным в надежности каждого звена в гетерогенной среде из различных компонент?

Здесь я согласен на 100%. Качественная языковая поддержка и контроль семантики со стороны компилятора действительно облегчает жизнь тем, кому необходимо разрабатывать конкретные прикладные решения.

Ответ на »сообщение 4849« (Стэн)
___________________________

Ответ на »сообщение 4845« (Илья Ермаков)
___________________________
Вот сейчас провожу нагрузочные тесты библиотеки на C++. Легкие актеры, описывающиеся как обыкновенные классы C++; взаимодействие только с помощью асинхронной посылки сообщений. С каждым физическим потоком ОС может быть связано произвольное кол-во объектов.
В результате получается: 300.000 объектов, на 4 физических потоках обмениваются сообщениями. И всё работает.
Что, по сравнению с Обероном, мой инструментарий не позволяет мне в этой области сделать?

Да, взглянул на Вашу реплику с другой стороны. Ведь Вы как раз и занимаетесь тем, что реализуете библиотеку для поддержки высокоуровневых параллельных абстракций. На С++. Что доказывает, что готовых-то решений у Вас нет :-)
И много труда, наверное, вложили... А в последних Оберонах все уже есть на уровне языка.
Вот Вам и отличие - Вы своими ногами идете обероновским путем, потому что стандартных решений ваш инструментарий не дает :-)

Ответ на »сообщение 4849« (Стэн)
___________________________

Ответ на »сообщение 4845« (Илья Ермаков)
___________________________
В результате получается: 300.000 объектов, на 4 физических потоках обмениваются сообщениями. И всё работает.
Что, по сравнению с Обероном, мой инструментарий не позволяет мне в этой области сделать?

Возможно, что и сильно сказано... Однако модель Active Oberon/Zonnon гораздо более высокоуровневая, нежели .NET/Java. Даже Ada 80-х более абстрактна в параллельности, чем они. Только до мониторов доскребли с горем пополам, абстракция активности все та же Thread в различных ООП-нутых оболочках...
Смоделировать-то активные объекты можно - только Вам это приходится делать искусственно, строить модель асинхронности для вашего приложения... Если язык поддерживает соответствующие абстракции, то асинхронное приложение получится почти автоматически в результате обычного ОО-проектирования. И будет готово задействовать все количество ядер, какое есть - и еще виртуальной асинхронности с головой останется...
Вопрос не в том "что не позволяет", а какой ценой и кровью... А как быть с компонентной средой? Если язык не поддерживает напрямую абстракций с жестким контролем компилятором и рантаймом, то как быть уверенным в надежности каждого звена в гетерогенной среде из различных компонент?
В Зоннон введены средства, позволяющие в EBNF описать протоколы взаимодействия - и вас проконтролирует компилятор и рантайм, ошибиться не получится.. То, что Зоннон пока идет медленно - другие причины, они завязали его на гранты Микрософта, а дальше уже пошла политика, как я понимаю...
Кстати, об абстракциях - помню, обсуждалась на RSDN проблема external lock для мониторов в .NET. Договорились до того, что "если любой дурак может снаружи заблокировать объект, то чтобы не произошло recursive lock, лучше не писать блокировку внутри метода, а всегда блокировать явно в каждой точке вызова метода"... Докатились, называется :-) Если блокировать снаружи, то какой это монитор и чем он отличается по уровню абстракции/инкапсуляции от критической секции?

А вот здесь я спрашиваю, потому, что действительно не понимаю. Что за автоматическая остановка объектов? Все объекты занимаются обработкой поступивших сообщений, если сообщений нет, они ждут. В какой момент они останавливаются?

Речь идет о механизме, при котором сборщик мусора при обнаружении активного объекта, на который нет внешних ссылок, выдает его активности стоп-сигнал, по которому она может завершиться. При этом должны корректно отрабатываться случаи, когда "живет" граф ссылающихся друг на друга объектов - вроде бы они взаимные "якори", но сборщик должен при отсутствиии ссылок на граф извне выдавать всем им стоп-сигнал... В известных реализациях активных объектов подобных механизмов нет. Пока активность работает, сборщик не трогает объект, он "сам себе якорь". Т.е. требуется явная остановка активности, как раньше требовалось явное освобождение памяти. Это архитектурный тормоз, особенно для компонентного ПО.

Ответ на »сообщение 4845« (Илья Ермаков)
___________________________
>>> RSDN-щики-императившики не знают и не могут знать, что такое активные объекты - ибо акромя абстракций Явы, Шарпа и ВинАпи ничего особенно не нюхали... Их инструментарий не позволяет писать приложения с асинхронностью в сотни и тысячи агентов... Обероны позволяют.

Сильное утверждение, можно с этого места поподробнее! Чем это C#/C++/Java или WinAPI не позволяют сделать активные объекты?
Вот сейчас провожу нагрузочные тесты библиотеки на C++. Легкие актеры, описывающиеся как обыкновенные классы C++; взаимодействие только с помощью асинхронной посылки сообщений. С каждым физическим потоком ОС может быть связано произвольное кол-во объектов.
В результате получается: 300.000 объектов, на 4 физических потоках обмениваются сообщениями. И всё работает.
Что, по сравнению с Обероном, мой инструментарий не позволяет мне в этой области сделать?

>>> Однако есть изюминка - автоматическая остановка активных объектов, это должно дать такой же эффект, какой в свое время дала сборка мусора - приводит к радикальным изменениям в проектировании, т.к. можно забыть о централизованном управлении объектами, их не нужно держать больше на коротком поводке, отпустил в систему - и забыл.

А вот здесь я спрашиваю, потому, что действительно не понимаю. Что за автоматическая остановка объектов? Все объекты занимаются обработкой поступивших сообщений, если сообщений нет, они ждут. В какой момент они останавливаются? Когда более нет ни кого, кто мог бы  отправить сообщение, или когда нет тех, кому можно послать сообщение?
Возможно, это действительно хорошая идея, но я не понимаю наличия противопоставления Оберона другим языкам?! Такую автоматическую остановку можно сделать в любом языке, поддерживающем сборку мусора.

Ответ на »сообщение 4847« (Jack Of Shadows)
___________________________

Ответ на »сообщение 4845« (Илья Ермаков)
___________________________
ы не обратили внимание и умолчали такую вещь, что этот веб-сервер крутился на спец. ОС, которая и обеспечивает легкое диспетчерирование тысяч потоков..
Тест YAWS vs Apache проводился на одной и той же OS - linux.

Да? Значит, я несколько неправ... Но тем не менее - это свой диспетчер потоков... Апач работает на нативных потоках. Суть в том, что пример сам по себе никакого отношения к сравнению "императив и функционал" не имеет. Впрочем, он показывает, что традиционный низкоуровневый Си-императив высокой асинхронности поддержать не может - это да.

Ответ на »сообщение 4845« (Илья Ермаков)
___________________________
ы не обратили внимание и умолчали такую вещь, что этот веб-сервер крутился на спец. ОС, которая и обеспечивает легкое диспетчерирование тысяч потоков..
Тест YAWS vs Apache проводился на одной и той же OS - linux.