OberonCore
https://forum.oberoncore.ru/

Уход от серверного режима к особому типу действий
https://forum.oberoncore.ru/viewtopic.php?f=127&t=6806		 Страница 2 из 3
Автор:  Иван Денисов [ Вторник, 05 Октябрь, 2021 11:47 ]
Заголовок сообщения:  Re: Уход от серверного режима к особому типу действий
Но вот теперь вопрос.
1. Особый запуск обычного действия
2. Отдельный тип для особых действий, установка обычным способом

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

Оба варианта в целом приемлемы. Но интересно понять некую статистику мнений.
Автор:  Иван Денисов [ Вторник, 05 Октябрь, 2021 11:49 ]
Заголовок сообщения:  Re: Уход от серверного режима к особому типу действий
budden писал(а):
Сказать же, что серверная программа должна работать без графического интерфейса - можно, но вообще говоря это не помогает. Представим себе самолёт. Ну разбили мы приложение на слои, и сервер, отвечающий за подачу топлива в двигатель, у нас работает теперь без сбоев. Но если приборная панель лагает, управлять таким самолётом всё равно нельзя.

Вот вот. Для многих задач разделение серверной и графической части на два отдельных приложения создаёт иллюзию лучшего контроля. Но в реальности получится задержка. Проблемы это не решает. По сути правильный цикл обработки мыши в таком случае должен дорисовывать горячие данные. И в Блэкбоксе такая возможность есть!
Автор:  Илья Ермаков [ Вторник, 05 Октябрь, 2021 14:08 ]
Заголовок сообщения:  Re: Уход от серверного режима к особому типу действий
Ну если UI верхнего уровня ведёт обмен с нижними неграфическими службами, то у него всё равно возникают задачи мягкого РВ, которые нужны, это так.

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

Ну и у Services.hook нужен отдельный метод Loop... ещё один тогда. LoopOnly...
Автор:  Иван Денисов [ Вторник, 05 Октябрь, 2021 14:10 ]
Заголовок сообщения:  Re: Уход от серверного режима к особому типу действий
Илья Ермаков писал(а):
Ну и у Services.hook нужен отдельный метод Loop... ещё один тогда. LoopOnly...

Да, так Антон и предлагает второй процедурой для крюка. Тут солидарен. И именно она идет в обработку к Input.
Автор:  Trurl [ Среда, 06 Октябрь, 2021 10:06 ]
Заголовок сообщения:  Re: Уход от серверного режима к особому типу действий
Цитата:
Actions are objects whose Do procedures are executed in a delayed fashion, when the system is idle.

Мне кажется, если нужно реальное время, стоит завести другой механизм
Автор:  Илья Ермаков [ Среда, 06 Октябрь, 2021 12:33 ]
Заголовок сообщения:  Re: Уход от серверного режима к особому типу действий
Trurl писал(а):
Цитата:
Actions are objects whose Do procedures are executed in a delayed fashion, when the system is idle.

Мне кажется, если нужно реальное время, стоит завести другой механизм


Речь о мягком реальном (например, обмен UI с сервером), который может гулять по гарантиям, но не должен блокироваться полностью.

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

Для графического ББ необходимо выдержать асинхронность/неблокированность примерно на уровне браузеров, скажем так. А там те же самые Services.Action, в общем-то. Только блокировки по мышке нет.
Автор:  Иван Денисов [ Четверг, 07 Октябрь, 2021 08:44 ]
Заголовок сообщения:  Re: Уход от серверного режима к особому типу действий
Trurl писал(а):
Цитата:
Actions are objects whose Do procedures are executed in a delayed fashion, when the system is idle.

Мне кажется, если нужно реальное время, стоит завести другой механизм


Вот тогда, пожалуй, ещё более правильно отделить тип, чтобы не нарушать документацию и даже назвать иначе...
BackgroundQuant подчеркнуло бы, что действие должно быть кратким по вычислительным ресурсам.
Автор:  Борис Рюмшин [ Четверг, 07 Октябрь, 2021 13:07 ]
Заголовок сообщения:  Re: Уход от серверного режима к особому типу действий
Формально то вывести сущность можно, чтобы что-то явно указывать при программировании. Но надо понимать, что модель выполнения это всё равно никак не изменит. Любое синхронное обращение, ну например, к ресурсу NFS, который отвалился, и всё, приплыли. Короче, гарантий никаких не будет.
Автор:  Иван Денисов [ Четверг, 07 Октябрь, 2021 13:24 ]
Заголовок сообщения:  Re: Уход от серверного режима к особому типу действий
Борис Рюмшин писал(а):
Формально то вывести сущность можно, чтобы что-то явно указывать при программировании. Но надо понимать, что модель выполнения это всё равно никак не изменит. Любое синхронное обращение, ну например, к ресурсу NFS, который отвалился, и всё, приплыли. Короче, гарантий никаких не будет.

Мы лишь добиваемся, чтобы обычные отложенные действия не вызывались во время обработки нажатия мыши. Но было средство, для запуска особых фоновых неграфических квантов вычислений.
Автор:  Wlad [ Четверг, 07 Октябрь, 2021 19:38 ]
Заголовок сообщения:  Re: Уход от серверного режима к особому типу действий
Пожалуйста, кто сможет, откликнитесь и ответьте на мои вопросы.

1) Я правильно понимаю, что в системе ЧЯ принципиально сохраняется "однопоточный" режим выполнения и он НИКОГДА не будет изменён ни под каким давлением или соображениями стороннего толка?
2) Я правильно понимаю, что есть желание применить КП/ЧЯ в системах РВ (степень "жёсткости" и степень применимости - предмет обсуждения, естественно!) ?
3) Я правильно понимаю, что сейчас стоит вопрос о ВОЗМОЖНЫХ пересмотре/переделке внутренних механизмов "планирования/выполнения задач" для получения более "отзывчивой" и "неблокируемой" системы?

Откуда "растут ноги" у появления запроса на подобные изыскания и обсуждения?
Если это - следствие какого-либо "заходящего" проекта, прошу сообщить мне в личку, почтой, в Телеге или - в Скайпе.
Автор:  Wlad [ Четверг, 07 Октябрь, 2021 20:14 ]
Заголовок сообщения:  Re: Уход от серверного режима к особому типу действий
Борис Рюмшин писал(а):
Формально то вывести сущность можно, чтобы что-то явно указывать при программировании. Но надо понимать, что модель выполнения это всё равно никак не изменит. Любое синхронное обращение, ну например, к ресурсу NFS, который отвалился, и всё, приплыли. Короче, гарантий никаких не будет.
Не совсем.
У меня есть опыт работы в строго "однопоточных" средах с собственным "планировщиком задач" во встраиваемых системах, где одновременно работают сотни "активных объектов" и работают они с кучей интерфейсов и служб.
Да, там - "немного" отличающиеся парадигмы и подходы к ПРОЕКТИРОВАНИЮ систем, но, в целом, они получаются даже проще и понятней тех, что основываются, например на pthreads. При этом, они ещё и "отзывчивей"/"реактивней" могут получиться!
По нескольким причинам:
1) механизм "планирования" проектируется не из "общих абстрактных соображений", а учитывает специфику работы системы
2) "элементы синхронизации" исполнения активностей объектов ("потоков") - прост, ясен и лёгок в реализации. И - полностью подконтролен.
3) нет потерь на сохранении/восстановлении контекстов исполнения. Кроме того, по сравнению с многопоточным подходом, он занимает, часто, на порядки меньше памяти (по сути на все "потоки" работает один и тот же стек).
4) единственный "тонкий нюанс" (особенно - для систем, работающих на "голом железе") - реакция на прерывания от интерфейсов и (хардовых)таймеров. Но это - естественный и, часто, единственный "нюанс" требующий повышенного внимания при проектировании и аккуратности при реализации.
5) отдельный вопрос - по дисциплине и подходам к "параллельно исполняющимся" активностям/потокам/задачам. Там есть два кардинально различающихся подхода: 1) классические обработчики состояний конечных автоматов, обрабатывающих поток событий и 2) система общей "псевдопоточности", когда нет строгой привязки к реализации в виде КА.

В любом случае, написано достаточно много реализаций "сред исполнения", как над многопоточными ОСями, так и над голым железом с "однопоточными" вариантами пользовательской части систем. Системы, в том числе, и жёсткого РВ (в том числе и - для авиакосмоса).
В качестве "мозгового упражнения" (с последующими случаями применения полученных результатов в реальных проектах) был написан универсальный вариант библиотеки "эмулирующий" "однопоточный подход" в многопоточных исполняющих средах. Это упрощает анализ системы и повышает гарантированность надёжности её работы. Ну - просто потому, что такие системы проще.
Автор:  Илья Ермаков [ Четверг, 07 Октябрь, 2021 20:22 ]
Заголовок сообщения:  Re: Уход от серверного режима к особому типу действий
Wlad писал(а):
Пожалуйста, кто сможет, откликнитесь и ответьте на мои вопросы.

1) Я правильно понимаю, что в системе ЧЯ принципиально сохраняется "однопоточный" режим выполнения и он НИКОГДА не будет изменён ни под каким давлением или соображениями стороннего толка?
2) Я правильно понимаю, что есть желание применить КП/ЧЯ в системах РВ (степень "жёсткости" и степень применимости - предмет обсуждения, естественно!) ?
3) Я правильно понимаю, что сейчас стоит вопрос о ВОЗМОЖНЫХ пересмотре/переделке внутренних механизмов "планирования/выполнения задач" для получения более "отзывчивой" и "неблокируемой" системы?

Откуда "растут ноги" у появления запроса на подобные изыскания и обсуждения?
Если это - следствие какого-либо "заходящего" проекта, прошу сообщить мне в личку, почтой, в Телеге или - в Скайпе.


1) Примерно так, но режим выполнения в отдельных потоках особой вычислительной логики, при безопасном обмене с главной логикой, делать можно.

2) Д. В. Дагаев применял ББ в системах такого класса, при этом телекоммуникационная часть была написана неблокирующим образом без многопоточности http://www.inr.ac.ru/~info21/oberon_inn ... tovAES.htm

3) В этой ветке Иван с Антоном подняли достаточно узкий вопрос - в графическом ББ возникают некоторые процессы, которым не следует быть блокируемыми какими-то графическими штуками (а ввод мыши в ситуациях типа Drag&Drop в ББ сделан блокирующим особым циклом).
Автор:  Борис Рюмшин [ Четверг, 07 Октябрь, 2021 22:00 ]
Заголовок сообщения:  Re: Уход от серверного режима к особому типу действий
Wlad писал(а):
Борис Рюмшин писал(а):
Формально то вывести сущность можно, чтобы что-то явно указывать при программировании. Но надо понимать, что модель выполнения это всё равно никак не изменит. Любое синхронное обращение, ну например, к ресурсу NFS, который отвалился, и всё, приплыли. Короче, гарантий никаких не будет.
Не совсем.
У меня есть опыт работы в строго "однопоточных" средах с собственным "планировщиком задач" во встраиваемых системах, где одновременно работают сотни "активных объектов" и работают они с кучей интерфейсов и служб.
Владимир, это я понимаю. Говорил только про текущую ситуацию с ББ.
Автор:  budden [ Четверг, 07 Октябрь, 2021 22:24 ]
Заголовок сообщения:  Re: Уход от серверного режима к особому типу действий
Борис Рюмшин писал(а):
Формально то вывести сущность можно, чтобы что-то явно указывать при программировании. Но надо понимать, что модель выполнения это всё равно никак не изменит. Любое синхронное обращение, ну например, к ресурсу NFS, который отвалился, и всё, приплыли. Короче, гарантий никаких не будет.

В тикле это решается тем, что все обращения являются асинхронными. Если есть что-то такое ужасное, что нельзя сделать асинхронным, то оно выносится в отдельный тред на уровне платформы и уже из этого треда слать события в общую очередь.
Автор:  Борис Рюмшин [ Четверг, 07 Октябрь, 2021 23:21 ]
Заголовок сообщения:  Re: Уход от серверного режима к особому типу действий
budden писал(а):
В тикле это решается тем, что все обращения являются асинхронными. Если есть что-то такое ужасное, что нельзя сделать асинхронным, то оно выносится в отдельный тред на уровне платформы и уже из этого треда слать события в общую очередь.

Да понятно, как оно может решаться. Но в ББ вполне конкретная модель и речь только о её уточнении, как правильно сказал Илья, в узком случае.
Автор:  Wlad [ Суббота, 09 Октябрь, 2021 14:24 ]
Заголовок сообщения:  Re: Уход от серверного режима к особому типу действий
Илья Ермаков писал(а):
3) В этой ветке Иван с Антоном подняли достаточно узкий вопрос - в графическом ББ возникают некоторые процессы, которым не следует быть блокируемыми какими-то графическими штуками (а ввод мыши в ситуациях типа Drag&Drop в ББ сделан блокирующим особым циклом).
я это понял.
Просто, из опыта, если подобного рода "вопрос"/"нюанс" возник в одном месте, то это - верная гарантия того, что нужно пересматривать и перепроектировать всю архитектуру системы.
Потому, что иначе всё скатится в "заплаточные" решения "по месту", без общей стройной идеологии и подходов к созданию частей системы.
Автор:  budden [ Суббота, 09 Октябрь, 2021 16:52 ]
Заголовок сообщения:  Re: Уход от серверного режима к особому типу действий
Согласен с предыдущим оратором, узкий вопрос явно является обсуждением того, как лучше приладить заплату. Однако явно что никто из реальных пользователей ББ не настроен делать ничего иного, поэтому больше не мешаю. Заплаты тоже имеют право на существование.
Автор:  Wlad [ Суббота, 09 Октябрь, 2021 17:36 ]
Заголовок сообщения:  Re: Уход от серверного режима к особому типу действий
budden писал(а):
Согласен с предыдущим оратором, узкий вопрос явно является обсуждением того, как лучше приладить заплату. ... Заплаты тоже имеют право на существование.

Коготок увяз - всей птичке пропАсть.
Автор:  adimetrius [ Суббота, 09 Октябрь, 2021 18:54 ]
Заголовок сообщения:  Re: Уход от серверного режима к особому типу действий
Коллеги, все верно, речь о том, как уже имеющуюся с версии 1.7 заплату переприделать слегка поэлегантнее.

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

Но есть вариации. Например, задачи, которые "терпят отлагательство", и/или могут быть без ущерба разделены на "кванты". Такие, с "логической многозадачностью", тоже можно в ББ решить. Или можно налаживать межпроцессное взаимодействие между запущенными экземплярами ББ, который всегда в многозадачной среде выполняется. Я полагаю, Йозефу можно было пойти этим путем: в одном ББ запустить его ХТТП-сервер, в другом - выделять спокойно мышью тексты и не беспокоиться, что сервер на время трассировки подвисает. Конечно, все эти IPC гораздо трудоемче, чем тот хак, который в версию 1.7 включили: изнутри Rider.Input выполнили все отложенные действия.

На перспективу мне бы хотелось такой эксперимент: запустить весь ББ внутри А2/ЯОС в качестве одного активного объекта. Вместе с его главной петлей обработки событий и вообще всем прочим хозяйством. А затем наладить взаимодействие между блэкбоксами, запущенными внутри одной А2 - только уже теми высокоуровневыми средствами, которые в родственном языке ETH Active Oberon предусмотрены. И тогда на КП можно решать задачи, которым принципиально не подходит однозадачность.
Автор:  Wlad [ Воскресенье, 10 Октябрь, 2021 02:43 ]
Заголовок сообщения:  Re: Уход от серверного режима к особому типу действий
adimetrius писал(а):
Коллеги, все верно, речь о том, как уже имеющуюся с версии 1.7 заплату переприделать слегка поэлегантнее.
Можно обозвать это не "заплатой", а - "элементом лоскутного одеяла" :)

adimetrius писал(а):
На мой взгляд, ББ это каркас принципиально с однозадачной архитектурой, предназначен для решения задач, которые решаются в такой архитектуре. Если стоят задачи, для которых не подходит однозадачная архитектура - знач, не подходит ББ. Переделывать его нет резона, как нет резона переделывать вилку, которой неудобно черпать суп.
Однозадачная архитектура подходит для всего. Просто там начинают явно в задачи лезть элементы устройства переключения контекстов и синхронизации. Но и они решаемы. Более того, иногда/часто, решения приводят к более элегантным и систематически разработанным архитектурам... реализации которых работают быстрее многопоточных аналогов и занимают меньше памяти.

adimetrius писал(а):
...задачи, которые "терпят отлагательство", и/или могут быть без ущерба разделены на "кванты".
Это - не то, что "лишние", а - ВРЕДНЫЕ характеристики для разбора предметки и имплементации работы активностей сущностей из предметки.

adimetrius писал(а):
На перспективу мне бы хотелось такой эксперимент: запустить весь ББ внутри А2/ЯОС в качестве одного активного объекта.
Извините, - что? Может вы имели в виду - компонента?

adimetrius писал(а):
Вместе с его главной петлей обработки событий
Там нет ничего подобного. Хотя и может быть реализовано в активности объекта.

adimetrius писал(а):
А затем наладить взаимодействие между блэкбоксами, запущенными внутри одной А2 - только уже теми высокоуровневыми средствами, которые в родственном языке ETH Active Oberon предусмотрены. И тогда на КП можно решать задачи, которым принципиально не подходит однозадачность.
Там были, как мне помнится, потоковые классы. Тогда (давно) их пользовали для коммуникации между объектами. В принципе, ничего не мешает организовать подобный механизм и в Винде или - в ПОЗИКС-системах (через системные очереди, разделяемую память, каналы...) Для этого надо будет вводить сущность типизированного канала (с блокировками по чтению или записи, или - без них). Но это потребует перестройки подходов к проектированию (архитектур реализуемых систем) РАДИКАЛЬНО. И - опять понесётся вой со стороны тех, кто привык тяпляпствовать.
Страница 2 из 3 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/