Здравствуйте, WolfHound, Вы писали:

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

Кому посылаются запросы и от кого получаются ответы?

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

С объектами существует множество разнообразный возможностей:

1. Полностью синхронный запрос-ответ за один процедурный вызов.

2. Разделить обработку на синхронную и асинхронную части. Это разделение осуществяется в серверном активном объекте. Когда синхронная часть завершена управление возвращается, а активный объект продолжает обрабатывать асинхронную часть.

3. Завести объекты-каналы. В них складывать запросы и доставать ответы. Синхронны только обращения к каналам.

4. Максимальный асинхронизм. Серверный объект на каждый запрос создаёт активный объект, который "ведёт" этот запрос.

WH>Особенно это хорошо если нужно послать сообщения по нескольким каналам и потом ждать от них ответа.

Из одного потока? Если да то зачем?

WH>Кстати как там с установкой таймаута при вызове активного объекта?

Таймер — это ещё один активный объект.
Он есть в комплекте поставки системы.

WH>Только ты забыл про то что это не только обычный вызов но еще и захват монитора.

Захват незахваченного монитора — это пара машинных инструкций.

WH>А во что это выльется хотябы на кластере я вобще подумать боюсь... кури DCOM и CORBA и то и другое работает весьма хреново ибо RPC, а RPC это ошибка природы и должен умереть. Вся эта "прозрачность" на практике не только ничего не дает но и мешает нормальной декомпозиции ситемы.

Прозрачность надо ставить не на уровне процедурных вызовов.

Активные объекты могут помочь и при кластерных вычислениях.

Здравствуйте, absolute, Вы писали:

WH>>В случае каналов я могу на произвольное колличество произвольных запросов получить произвольное колличество произвольных ответов.
A>Кому посылаются запросы и от кого получаются ответы?
Ты вобще описание модели читал или просто поспорить решил?

WH>>А в случае с объектами я могу на один конкретный запрос получить только один конкретный ответ.
A>С объектами существует множество разнообразный возможностей:
A>1. Полностью синхронный запрос-ответ за один процедурный вызов.
На соседний комп? Или в соседний процесс? Так там всеравно будут асихронные сообщения...

A>2. Разделить обработку на синхронную и асинхронную части. Это разделение осуществяется в серверном активном объекте. Когда синхронная часть завершена управление возвращается, а активный объект продолжает обрабатывать асинхронную часть.
Ахринеть... это для того чтобы отаслать данные на сервер мне нужно будет всеравно дождатся ответа? А зачем?
Только не говори про подтверждение доставки. На практике в большинстве случаев нужно отправить несколько сообщений и на все разом получить ответ.
Например протокол HTTP очень хорошо раскладывается на серию сообщений сначала в одну сторону, а потом в другую.

A>3. Завести объекты-каналы. В них складывать запросы и доставать ответы. Синхронны только обращения к каналам.
Закат солнца в ручную? Конечно можно но зачем?

A>4. Максимальный асинхронизм. Серверный объект на каждый запрос создаёт активный объект, который "ведёт" этот запрос.
И как мне обработать некий протокол? На пример тотже HTTP? И это еще очень простой протокол.

WH>>Особенно это хорошо если нужно послать сообщения по нескольким каналам и потом ждать от них ответа.
A>Из одного потока? Если да то зачем?
Что зачем?
Опрос нескольких сервисов происходит сплошь и рядом.

WH>>Кстати как там с установкой таймаута при вызове активного объекта?
A>Таймер — это ещё один активный объект.
A>Он есть в комплекте поставки системы.
Ну и как будет выглядеть аналог кода

match (channel.Receive(timeout))
{
| Message1 as msg => ...
| Message2 as msg => ...
| Message3 as msg => ...
| None => ...
}

A>Захват незахваченного монитора — это пара машинных инструкций.
А захват монитора на соседнем компе или хотябы в соседнеднем процессе?

A>Прозрачность надо ставить не на уровне процедурных вызовов.
А куда?

A>Активные объекты могут помочь и при кластерных вычислениях.
Правда? Я вот прямо сейчас в этих самых кластерных вычислениях и активных объектах общение с которыми идет через CORBA. Так вот я с большим удовольствием бы сменил корбу на каналы.
Провести распределенную транзакцию на корбячих вызовах это тАкой геморой что

Здравствуйте, WolfHound, Вы писали:

AVC>>>>Например, процессы не могут обмениваться между собой объектами.
WH>>>Могут по значению.
AVC>>С методами?
WH>Зачем? Сейчас все больше народ склоняется к передачи просто структуированных данных без поведения.
WH>Передача объектов с поведением это вобще весьма проблемная задача с кучей подводных камней из серии где выполнять методы, какие у этих методов права и тп...

Допустим, виноград пока что зелен.
Но вопрос "зачем?" кажется странным.
Объекты желательно передавать по той же причине, по какой их вообще используют: в отличие от пассивных данных, объекты обладают поведением.
О чем ты сам и сказал. (Поэтому и вопрос странный.)
Действительно, пересечение объектом границ процесса может вызывать трудности.
Так, может быть, не всегда уместно все пилить на процессы?

Здравствуйте, AVC, Вы писали:

AVC>Допустим, виноград пока что зелен.
AVC>Но вопрос "зачем?" кажется странным.
AVC>Объекты желательно передавать по той же причине, по какой их вообще используют: в отличие от пассивных данных, объекты обладают поведением.
AVC>О чем ты сам и сказал. (Поэтому и вопрос странный.)
AVC>Действительно, пересечение объектом границ процесса может вызывать трудности.
Вот по этому объекты между процессами гоняют все меньше. Ибо проблем больше чем пользы.

AVC>Так, может быть, не всегда уместно все пилить на процессы?
А кто говорил что пилить нужно обязательно все?
Если задачу не нужно пилить на процессы то для общения внутри процесса можно использовать каналы без ограничений на передачу объектов по ссылке.
Но если у нас появляются слова клиент/сервер то дробление на процессы просто не избежно. И гонять объекты с поведением между клиентом и сервером гемор еще тот, а ели вдруг появляется передача по ссылке то вобще тушите свет.
Еще у дробления на процессы есть очень циничная возможность:
Дело в том что в управляемой ОС создание процесса можно сделать ооочень дешовым таким образом мы можем вернутся к концепции процесс на запрос но на этот раз причина не в надежности(она и так на высоте), а в оптимизации. В таких процессах которые только и делают что генерируют HTML по XML можно не использовать ГЦ вобще и запретить создовать другие потоки в нутри этого процесса. Те память будет выделятся только на стеке и в хипе который доживет до конца. Плюс в хипе не будет никакой синхронизации что тоже благотворно скажется на производительности. Плюс агрессивные оптимизации могут устранять не только не используемые методы но и поля объектов ибо всеь код который будет работать в этом процессе известен.