OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 19 Март, 2024 06:13

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 59 ]  На страницу Пред.  1, 2, 3
Автор Сообщение
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 20:35 

Зарегистрирован: Вторник, 01 Январь, 2008 16:19
Сообщения: 35
Цитата:
Там как раз идёт усиление гарантий - и в итоге разработчик имеет абстракцию надёжного канала, и уже не должен контролировать корректность передачи данных. Ошибки обрабатываются ниже.

имеются ввиду не те ошибки. ошибки передачи пакетов разумеется не могут выноситься на уровень не только прикладного программирования, но и даже программирования самой оси. они закрыты внутри реализаций протоколов. ошибки в виде разрыва канала связи и его восстановления(если оно произошло в течении некотрого промежутка времени) тоже закрыты в соотв. реализациях протоколов.
имеется ввиду, если уж брать аналогию с tcpip просто отсутствие данного ip адреса. и недостаточной реальной гарантированности посылки мессаги.

Цитата:
По такому же принципу можно "наслоить" между сетевым соединением и descriptor.Call слой, который "дообеспечивает". И в случае отказа соединения, исчезновения объекта и т.п. этот слой не должен выплёскивать проблему клиентскому коду, а должен приводить в действие какие-то спец. обработчики исключения, которые уже принимают конкретные решения - восстанавливать соединение, пересоздавать объект, предложить объект-заменитель, сообщить об ошибке кому-либо и т.п.
Обработкой этого занимается само приложение, но не в тех местах, где описана логика нормального взаимодействия (идут прозрачные вызовы), а в обособленных обработчиках. Т.е. основной код "прозрачен", а разница в гарантиях компенсируется специальными сценариями, которые приходят в действие в особых ситуациях.


не нужно никаких сценариев. поскольку общего, даже приблизительно сценария для обьекта-заглушки, старающего сэмулировать пропавший удаленный реальный обьект нет. либо такие заглушки нужно писать руками, и предоставлять как реализацию актера, так и реализацию "глухого актера". лишнее это.
просто нужно уметь проверять доставлено ли ваше сообщение, у сообщения должны быть методы -
bool is_received(); //неблокирующая проверка доставки
bool wait_is_received(timeout);//блокирующая, то есть текущий тред встает в ожидание события доставки с таймаутом.
и опять таймауты вылезают на уровень прикладного программирования, поскольку даже если вы пишете простой текстовый коммуникатор по радиоканалу типа точка-точка, вам придется убеждаться в успехе доставки ваших сообщений в прикладном коде. и этот код должен уметь варьировать таймаут. например его увеличить или уменьшить.

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

Цитата:
Тут же к вопросу об обработке исключений - мне кажется, что конструкции try-except (в полезности которых многие давно сомневались) совершенно бесполезны в параллельных приложениях. Т.к. искать обработчик исключительной ситуации раскруткой стека текущего потока бессмысленно, этот поток не может и не должен ничего знать об обработке исключений (а если всё-таки должен, то достаточно обычных кодов ошибок).

полезность исключительных ситуаций формально постулируется так. не помню автора, возможно майер(если не ошибаюсь), автор Эйфеля.
исключительная ситауция должна возникнуть тогда, когда функция проверив на корректность предусловия, не может своим кодом выполнить постусловия. Все остальное от лукавого. То есть с точки зрения теории, выход из функции заперт невыполнимыми постусловиями. тогда необходима иная форма выхода - что и есть генерирование искл. ситуации.
Любовь к исключениям просто для передачи результата навроде - хотели файл открыть а его нету! это вульгарное использование механизма исключений, порождающее споры с мордобоем, зачем они вообще.
Исходя из определения видно, что если вы ослабите постусловия функций, вы теоретически можете сократить необходимость исключений до нуля - при постусловиях, что любая постситуация не нарушает корректности функции.
то есть спор - нужно-не нужно абстрактен. зависит от того, какими вы видите постусловия ваших функций. лично я исключения стараюсь не использовать вообще, если это в моей власти.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 21:35 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
merk писал(а):
с жестоким использованием ООП. и к тому ж работающих в жестких условиях аппартных органичений и каналов связи.
А разве в таких условиях можно использовать ООП с его оверхедом из-за виртуальных методов, иерархий бесполезных классов и т.д.?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 21:36 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Илья Ермаков писал(а):
Что-то я такого не припоминайт...
Откуда информация?
Если судите по Oberon-SA, то это ж язык для встроенных StrongARM, там, в принципе, он мог быть исключен.
Из 07-мя (насколько помню виденный у info21 его проект), он исключен не будет.
Да всё из этого самого, из Oberon-SA -- прототипа Оберона-07...
Когда, кстати, описание-то виртово появится? Ещё полгода назад объявляли, а до сих пор ни слуху, ни духу... А Вы ещё возмущаетесь, что проныры-американцы отовсюду вытеснили нерасторопную европейскую школу... :о))


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 21:59 

Зарегистрирован: Вторник, 01 Январь, 2008 16:19
Сообщения: 35
Цитата:
А разве в таких условиях можно использовать ООП с его оверхедом из-за виртуальных методов, иерархий бесполезных классов и т.д.?

затраты на вызов вирт. метода пренебрежимо малы по сравнению с основной логикой оси. :D
затем если вы заметили, ось в основном спит, поскольку число системных вызовов незначительно по сравнению с работой кода прикладных программ. в средне-нагруженной системе. собственная работа ядра оси, связанная с работой таймеров, переключением тредов и проч, составляет в общем случае несколько процентов от общей производительности.
да и вообще, любая ось по определению должна работать мало, по сравнению с поддерживаемыми ею задачами. иначе вычислительная мощь системы поддерживает только функционирование оси - как абстракции между прикладной задачей и железной платформой. куда это годится? либо платформа слаба, либо ось перенаворочана.
в условиях когда система загружена под завязку, процессор всегда занят, ни о какой реальной реалтаймовости говорить уже нельзя. в таких условиях система по любому отстает от внешних событий. то есть для реальной рилтамовости нужна загрузка проца ..ну там процентов 50. остальное время от стоит наготове. :)
иерархии бесполезных классов пишутся самими программистами. удалите бесполезные классы. равно - удаляйте бесполезные функции из программы на каком-нить не ооп языке.
короче проблем никаких.
могут быть проблемы с чрезмерной работой на куче, если обьекты оси активно ею пользуются, что возможно при ооп. но ядро не рождает-убивает обьекты постоянно при своей работе. оно их генерит для какого-то использования и обычно они живут все время сессии работы.
короче ерунда.
писать оси на си стоит только из требований немеряной переносимости или по требованию каких-то стандартов или заказчиков. если у вас есть свобода выбора, ооп лучше.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 22:11 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
merk писал(а):
то есть для реальной рилтамовости нужна загрузка проца ..ну там процентов 50. остальное время от стоит наготове.
Где-то мне попадалось утверждение, что в реал-тайм системе должен быть десятикратный запас по мощности оборудования... :о))

merk писал(а):
иерархии бесполезных классов пишутся самими программистами. удалите бесполезные классы. равно - удаляйте бесполезные функции из программы на каком-нить не ооп языке.
короче проблем никаких.
Разве? Мёртвый код в процедурных/функциональных языках может быть легко удалён транслятором, а в ООП-языках? Кто его знает, когда, кто и как будет вызывать виртуальные методы, которые могут быть уточнены лишь во время работы программы? Вот и придётся на всякий случай хранить иерархии бесполезных классов...
Для работы в "в жестких условиях аппартных органичений" это может быть критично...

merk писал(а):
писать оси на си стоит только из требований немеряной переносимости или по требованию каких-то стандартов или заказчиков. если у вас есть свобода выбора, ооп лучше.
А вот есть примеры написания операционных систем на функциональных языках типа Хаскелл, SASL, Lisp...
Что Вы думаете по этому поводу? ;о)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 22:34 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Geniepro писал(а):
Когда, кстати, описание-то виртово появится? Ещё полгода назад объявляли, а до сих пор ни слуху, ни духу... А Вы ещё возмущаетесь, что проныры-американцы отовсюду вытеснили нерасторопную европейскую школу... :о))

Тише едешь - дальше будешь...
Семь раз отмерь...
- как гласит народная мудрость... и пусть себе космические корабли бороздят Большой тяатр :-)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 22:39 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
merk писал(а):
не нужно никаких сценариев. поскольку общего, даже приблизительно сценария для обьекта-заглушки, старающего сэмулировать пропавший удаленный реальный обьект нет. либо такие заглушки нужно писать руками, и предоставлять как реализацию актера, так и реализацию "глухого актера". лишнее это.
просто нужно уметь проверять доставлено ли ваше сообщение, у сообщения должны быть методы -
bool is_received(); //неблокирующая проверка доставки
bool wait_is_received(timeout);//блокирующая, то есть текущий тред встает в ожидание события доставки с таймаутом.
...
и опять таймауты вылезают на уровень прикладного программирования, поскольку даже если вы пишете простой текстовый коммуникатор по радиоканалу типа точка-точка, вам придется убеждаться в успехе доставки ваших сообщений в прикладном коде. и этот код должен уметь варьировать таймаут. например его увеличить или уменьшить.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 22:43 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
merk писал(а):
полезность исключительных ситуаций формально постулируется так. не помню автора, возможно майер(если не ошибаюсь), автор Эйфеля.
исключительная ситауция должна возникнуть тогда, когда функция проверив на корректность предусловия, не может своим кодом выполнить постусловия. Все остальное от лукавого. То есть с точки зрения теории, выход из функции заперт невыполнимыми постусловиями. тогда необходима иная форма выхода - что и есть генерирование искл. ситуации.
Любовь к исключениям просто для передачи результата навроде - хотели файл открыть а его нету! это вульгарное использование механизма исключений, порождающее споры с мордобоем, зачем они вообще.


Прекрасная формулировка! Я Мейера не читал, но сам по размышлении сформулировал этот принцип именно так. Исключения должны генерироваться только тогда, когда функция не может обеспечить свой контракт. А единственный случай, когда функция имеет право не обеспечить контракт - если под ней лежит некая ненадёжная среда (ввод-вывод, сеть), а выносить эту ненадёжность для клиентов наверх (через коды ошибок) она не хочет (слишком высокоуровневая). Вот тут-то и требуется обработка исключений.
Только я за то, чтобы не раскручивать стек до ближайшего except-а, а делать спец. ОО-хуки, которые клиент некоторой службы к ней подключает (говоря "если не можешь обеспечить контракт, сигналь мне сюды, а я буду разбираться, что делать далее"). Т.е. обработка исключений обычными ОО-паттернами.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 22:46 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
merk писал(а):
по поводу инверсии приоритетов. проблема чиста академическая. в реальности, в хорошо спроектрованной системе треды высокоприоритетные не видят тредов низкого приоритета. ничего о них не знают.

Нууу, мне кажется, Вы идеализируете.
Иначе требование к защите от инверсии приоритетов не являлось бы обязательным для каждой ОС реального времени.

Разрабатывая законченную монолитную РВ-систему, можно "вылизать" её так, чтобы избежать инверсии. Но где-то выше Вы уже совершенно правильно замечали, что если система расширяемая, т.е. к ней могут подключаться компоненты (читай - потоки), о которых ничего не известно на этапе разработки, то никаких предположений относительно того, что они "хорошо спроектированы" делать мы не можем. Нужна какая-то техническая защита от проблем, которую эти компоненты могут породить.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 22:58 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
merk писал(а):
писать оси на си стоит только из требований немеряной переносимости или по требованию каких-то стандартов или заказчиков. если у вас есть свобода выбора, ооп лучше.


По поводу ООП - конечно, это не препятствие для ОС.
Но по поводу Си я бы назвал два важных аргумента:
1) Си - компактный язык. С++ - навороченный бронтозавр, а значит - ошибко/проблемо-опасен. Единственный вариант "лечения" - работать на жёстко определённом подмножестве. "Административные меры".
2) Следствие п. 1 - нет ни одного 100%-правильного и/или соотв. стандарту компилятора С++.

И можно привести п.3, касающийся ООП в С++ - и не только в С++, а в немодульных языках вообще.
Инкапсуляция и сокрытие информации в них возложено на классы (т.е. модульность эмулируется классами).
Для системного программирования характерны группы мелких классов, тесно взаимодействующих друг с другом. Таким образом, нужно либо чрезмерно открывать интерфейсы, либо терять эффективность, либо хитрить с несколькими интерфейсами (.h-файлами, для "своих" и "чужих") да использовать "костыли" типа friend.
В модульных языках проблема решается изящно - инкапсуляция возложена на модули. Группа типов ("классов"), объявленных в одном модуле, имеет полный доступ к полям друг друга. Так называемое no paranoia rule. Что и требуется для системного программирования.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 23:02 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Илья Ермаков писал(а):
Тише едешь - дальше будешь...
Семь раз отмерь...
- как гласит народная мудрость...
Как сказал Фоменко -- пока семь раз отмеришь, другие уже отрежут.
Что мы и наблюдаем повсеместно... :о))


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Январь, 2008 23:03 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Да всё идёт путём... Критерий своевременности - это успевание решать реальные поступающие задачи, а не скорость генерации/комбинирования тулзов и фич :-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Январь, 2008 23:48 

Зарегистрирован: Вторник, 01 Январь, 2008 16:19
Сообщения: 35
Цитата:
Где-то мне попадалось утверждение, что в реал-тайм системе должен быть десятикратный запас по мощности оборудования... :о))


ну это вопрос трактовки того, насколько система должна быть реактивна.
если требуется чтобы система жестко(то есть мгновенно) реагировала на события, они ею обрабатывались и результат за минимально возможное время выводился наружу..ну например управляя каким-нить устройством, то очевидно что проц должен быть свободен от обработки событий такого же уровня приоритета как и поступившее или выше. иначе он не прервется.
но это предельный рилтайм. чисто статистически проц должен быть в основном свободен. грубо говоря чтобы задержки возникали лишь в 10 процентах случаев.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Январь, 2008 00:30 

Зарегистрирован: Вторник, 01 Январь, 2008 16:19
Сообщения: 35
Цитата:
Почему бы не позволить прикладнику написать 95% кода "чисто", поверх "надёжных" абстракций, а затем собрать в одном месте, в спец. компоненте всю логику обработки отказов?

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

Цитата:
Разрабатывая законченную монолитную РВ-систему, можно "вылизать" её так, чтобы избежать инверсии. Но где-то выше Вы уже совершенно правильно замечали, что если система расширяемая, т.е. к ней могут подключаться компоненты (читай - потоки), о которых ничего не известно на этапе разработки, то никаких предположений относительно того, что они "хорошо спроектированы" делать мы не можем. Нужна какая-то техническая защита от проблем, которую эти компоненты могут породить.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Январь, 2008 00:36 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Почему? Любой прикладной актёр является клиентом системного. В сложных системах имеют право быть обратные связи от службы к клиенту. Системный актёр обрабатывает запрос от прикладного, даёт на него, так скажем, callback - и оказывается в зависимости от его низкого приоритета.
Почему бы не привязать понятие приоритета к сообщениям, а не к актёрам?

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Январь, 2008 00:39 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
merk писал(а):
если вы говорите об инкапсуляции, то обрабатывать отказы из разных модулей в одном месте - наверняка вытащить ненужную внутреннюю требуху этих модулей. я бы не советовал потому заниматься централизациями.
самое милое дело обработать отказ в пределах того блока, в котором он возник. поскольку там контекст отказа полный.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Январь, 2008 01:09 

Зарегистрирован: Вторник, 01 Январь, 2008 16:19
Сообщения: 35
te]В сложных системах имеют право быть обратные связи от службы к клиенту. [/quote]
обратные связи быть могут. но оформляются они специальным образом.
если сервер обслуживает N клиентов, он заводит N тредов обслуживания, и общается с каждым из клиентов отдельно в индивидуальном треде. такой тред не является критическим тредом для работы всей службы, и его блокировка службе жизнь не портит. критические треды службы клиенты видеть не могут. я об этом и говорю. если тред обслуживания заблокируется клиентом, то за счет таймаута, он выскочит из блокировки, и сообщит самой службе, что клиент умер, отвис, не отвечает, и служба решит скорее всего тред замочить, канал закрыть и записать что-то в лог. и усе.

Цитата:
Почему бы не привязать понятие приоритета к сообщениям, а не к актёрам?

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Январь, 2008 01:24 

Зарегистрирован: Вторник, 01 Январь, 2008 16:19
Сообщения: 35
Цитата:
Системный актёр обрабатывает запрос от прикладного, даёт на него, так скажем, callback - и оказывается в зависимости от его низкого приоритета.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Январь, 2008 18:50 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
merk писал(а):
у вас колбеки дает клиент, а система их вызывает. за счет модификации кода колбеков система обявляется расширяемой, насколько я понимаю.

Коллбэк - конкретизация какого-либо аспекта функциональности, "недоопределённой" на более высоком уровне абстракции в системе (в фреймвоке, например).
В нормальных условиях и проектах ничего более возвращение чего-то из ряда определённого набора значений (типов) (или их диапазонов) коллбэк обычно не делает...
К тому же на синхронном обмене колбэки - нонсенс (да и на уровне прикладного программиста, по большому счёту - тоже.... )

Кроме того, использование блокирования без возможности раблокировки по условию (например - таймауту, аки в QNX) - не то, что "нонсенс", а просто - в высшей степени - моветон-с...

----------------
Хотелоось бы "сместить акценты". Насколько облегчится рассмотрение блокировок, если в обсуждении будут использоваться не выражения, типа "очередь на потоке" или "очередь на активном объекте" , а - "очередь на канале"....


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 59 ]  На страницу Пред.  1, 2, 3

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB