OberonCore

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

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




Начать новую тему Ответить на тему  [ Сообщений: 51 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: Вторник, 05 Октябрь, 2021 11:47 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Но вот теперь вопрос.
1. Особый запуск обычного действия
2. Отдельный тип для особых действий, установка обычным способом

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

Оба варианта в целом приемлемы. Но интересно понять некую статистику мнений.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 05 Октябрь, 2021 11:49 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
budden писал(а):
Сказать же, что серверная программа должна работать без графического интерфейса - можно, но вообще говоря это не помогает. Представим себе самолёт. Ну разбили мы приложение на слои, и сервер, отвечающий за подачу топлива в двигатель, у нас работает теперь без сбоев. Но если приборная панель лагает, управлять таким самолётом всё равно нельзя.

Вот вот. Для многих задач разделение серверной и графической части на два отдельных приложения создаёт иллюзию лучшего контроля. Но в реальности получится задержка. Проблемы это не решает. По сути правильный цикл обработки мыши в таком случае должен дорисовывать горячие данные. И в Блэкбоксе такая возможность есть!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 05 Октябрь, 2021 14:08 
Модератор
Аватара пользователя

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

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

Ну и у Services.hook нужен отдельный метод Loop... ещё один тогда. LoopOnly...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 05 Октябрь, 2021 14:10 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Илья Ермаков писал(а):
Ну и у Services.hook нужен отдельный метод Loop... ещё один тогда. LoopOnly...

Да, так Антон и предлагает второй процедурой для крюка. Тут солидарен. И именно она идет в обработку к Input.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 06 Октябрь, 2021 10:06 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1428
Цитата:
Actions are objects whose Do procedures are executed in a delayed fashion, when the system is idle.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 06 Октябрь, 2021 12:33 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
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 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Trurl писал(а):
Цитата:
Actions are objects whose Do procedures are executed in a delayed fashion, when the system is idle.

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


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 07 Октябрь, 2021 13:07 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Формально то вывести сущность можно, чтобы что-то явно указывать при программировании. Но надо понимать, что модель выполнения это всё равно никак не изменит. Любое синхронное обращение, ну например, к ресурсу NFS, который отвалился, и всё, приплыли. Короче, гарантий никаких не будет.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 07 Октябрь, 2021 13:24 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Борис Рюмшин писал(а):
Формально то вывести сущность можно, чтобы что-то явно указывать при программировании. Но надо понимать, что модель выполнения это всё равно никак не изменит. Любое синхронное обращение, ну например, к ресурсу NFS, который отвалился, и всё, приплыли. Короче, гарантий никаких не будет.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 07 Октябрь, 2021 19:38 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
Пожалуйста, кто сможет, откликнитесь и ответьте на мои вопросы.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 07 Октябрь, 2021 20:14 

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 07 Октябрь, 2021 20:22 
Модератор
Аватара пользователя

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

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

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


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

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

3) В этой ветке Иван с Антоном подняли достаточно узкий вопрос - в графическом ББ возникают некоторые процессы, которым не следует быть блокируемыми какими-то графическими штуками (а ввод мыши в ситуациях типа Drag&Drop в ББ сделан блокирующим особым циклом).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 07 Октябрь, 2021 22:00 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Wlad писал(а):
Борис Рюмшин писал(а):
Формально то вывести сущность можно, чтобы что-то явно указывать при программировании. Но надо понимать, что модель выполнения это всё равно никак не изменит. Любое синхронное обращение, ну например, к ресурсу NFS, который отвалился, и всё, приплыли. Короче, гарантий никаких не будет.
Не совсем.
У меня есть опыт работы в строго "однопоточных" средах с собственным "планировщиком задач" во встраиваемых системах, где одновременно работают сотни "активных объектов" и работают они с кучей интерфейсов и служб.
Владимир, это я понимаю. Говорил только про текущую ситуацию с ББ.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 07 Октябрь, 2021 22:24 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Борис Рюмшин писал(а):
Формально то вывести сущность можно, чтобы что-то явно указывать при программировании. Но надо понимать, что модель выполнения это всё равно никак не изменит. Любое синхронное обращение, ну например, к ресурсу NFS, который отвалился, и всё, приплыли. Короче, гарантий никаких не будет.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 07 Октябрь, 2021 23:21 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
budden писал(а):
В тикле это решается тем, что все обращения являются асинхронными. Если есть что-то такое ужасное, что нельзя сделать асинхронным, то оно выносится в отдельный тред на уровне платформы и уже из этого треда слать события в общую очередь.

Да понятно, как оно может решаться. Но в ББ вполне конкретная модель и речь только о её уточнении, как правильно сказал Илья, в узком случае.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 09 Октябрь, 2021 14:24 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
Илья Ермаков писал(а):
3) В этой ветке Иван с Антоном подняли достаточно узкий вопрос - в графическом ББ возникают некоторые процессы, которым не следует быть блокируемыми какими-то графическими штуками (а ввод мыши в ситуациях типа Drag&Drop в ББ сделан блокирующим особым циклом).
я это понял.
Просто, из опыта, если подобного рода "вопрос"/"нюанс" возник в одном месте, то это - верная гарантия того, что нужно пересматривать и перепроектировать всю архитектуру системы.
Потому, что иначе всё скатится в "заплаточные" решения "по месту", без общей стройной идеологии и подходов к созданию частей системы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 09 Октябрь, 2021 16:52 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Согласен с предыдущим оратором, узкий вопрос явно является обсуждением того, как лучше приладить заплату. Однако явно что никто из реальных пользователей ББ не настроен делать ничего иного, поэтому больше не мешаю. Заплаты тоже имеют право на существование.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 09 Октябрь, 2021 17:36 

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

Коготок увяз - всей птичке пропАсть.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 09 Октябрь, 2021 18:54 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Коллеги, все верно, речь о том, как уже имеющуюся с версии 1.7 заплату переприделать слегка поэлегантнее.

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

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

На перспективу мне бы хотелось такой эксперимент: запустить весь ББ внутри А2/ЯОС в качестве одного активного объекта. Вместе с его главной петлей обработки событий и вообще всем прочим хозяйством. А затем наладить взаимодействие между блэкбоксами, запущенными внутри одной А2 - только уже теми высокоуровневыми средствами, которые в родственном языке ETH Active Oberon предусмотрены. И тогда на КП можно решать задачи, которым принципиально не подходит однозадачность.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 10 Октябрь, 2021 02:43 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
adimetrius писал(а):
Коллеги, все верно, речь о том, как уже имеющуюся с версии 1.7 заплату переприделать слегка поэлегантнее.
Можно обозвать это не "заплатой", а - "элементом лоскутного одеяла" :)

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

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

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

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

adimetrius писал(а):
А затем наладить взаимодействие между блэкбоксами, запущенными внутри одной А2 - только уже теми высокоуровневыми средствами, которые в родственном языке ETH Active Oberon предусмотрены. И тогда на КП можно решать задачи, которым принципиально не подходит однозадачность.
Там были, как мне помнится, потоковые классы. Тогда (давно) их пользовали для коммуникации между объектами. В принципе, ничего не мешает организовать подобный механизм и в Винде или - в ПОЗИКС-системах (через системные очереди, разделяемую память, каналы...) Для этого надо будет вводить сущность типизированного канала (с блокировками по чтению или записи, или - без них). Но это потребует перестройки подходов к проектированию (архитектур реализуемых систем) РАДИКАЛЬНО. И - опять понесётся вой со стороны тех, кто привык тяпляпствовать.


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

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


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

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


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

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