OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 29 Март, 2024 01:48

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




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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
В Блэкбоксе <=1.6 действия Services.Action не выполняются во время обработки трекинга мыши f.Input(...).
Соответственно любая обработка приходящих/отправляемых данных, повешенная на действия, приостанавливается.
Для ряда задач это критично, так как пользователь может долго выделять что-то мышью, порождая нежелательные задержки.

Для решения этой проблемы после некоторых дискуссий в Центре был добавлен серверный режим, который выполняет действия прямо в цикле обработки трекинга мыши.

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

Для надёжности мы предлагаем отделить такие действия, выполняемые в петле обработки мыши отдельно.
1. Либо, запуская такие действия по особенному
Services.DoLaterTrackable(a: Action; notBefore: INTEGER)
2. Либо, выделяя в отдельный класс
ServerAction = POINTER TO ABSTRACT RECORD (Action);


Оба решения позволят полностью отказаться от специального серверного режима.

Интересно мнение разработчиков. Выскажитесь, пожалуйста, чтобы нам принять более взвешенное решение для Блэкбокса 2.0.


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
А как будет строиться выполнение параллельно с циклом мыши?

Это же конкурентность может возникнуть, со всеми вытекающими...


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

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Илья, если я вас правильно понял, то именно это меня и напрягло. В вопросе я бы заменил будущее на настоящее: "А как строится выполнение параллельно с циклом мыши?".

В HostPorts.Input я увидел, посреди всяких вычислений координат мыши и кадров, вызов Services.actionHook.Step, т.е. выполнение всех действий с наступившим сроком. И крайне удивился. Поскольку у ББ принципиально однопоточная архитектура, и каждой команде гарантируется, что она единственная выполняется в отдельный момент времени (и след-но полноправно распоряжается всеми глобальными данными). Действия Services.Action - это подвид команд, которые выполняются отложенно. И тут вдруг выясняется, что при КАЖДОЙ трассировке нажатой мыши (т.е. когда организуется цикл REPEAT ... f.Input(...) UNTIL ~isDown, выполняются все отложенные команды с наступившим сроком. Т.е. фактически разрушается однопоточность.

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

ИМХО, это вообще никуда не годится. Однако если уже сложилась такая практика у кого-то, то, по крайней мере, хочется отделить действия, которые могут делать все что угодно, от действий, которые ограничены в возможностях. Ограниченные действия можно, прищурив один глаз, вызывать из HostPorts.Input, а прочие - только по окончании всех других команд. Ну и в документации предупредить, что ограниченные действия потенциально опасны, и почему.


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

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Мне немного непонятно, а чего там нарушается то? Services.Action это другой вариант фоновых задач из оригинальной системы Оберон (https://oberoncore.ru/_media/library/wi ... system.pdf, гл. 3). Поэтому система то однопоточная (хотя не совсем), но многозадачная (кооперативная многозадачность). Ясное дело, что при "грамотно" написанной задаче (да ещё и без диспетчера, либо как в Go, либо чисто ядерного), можно легко положить систему. Там да, была проблема, что всё клинило каких-то действиях (например при выборе чего-то из меню). Можно, конечно, убрать вызов Step оттуда, но с другой стороны, Action должны быть написаны аккуратно, с пониманием происходящего.

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

А реальный серверный софт пишется без графического каркаса.


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Так как это не только для сетевого софта важно, но и при сборе данных с измерительного оборудования, то хотелось бы иметь более надёжное документированное решение.

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

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


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

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Ну я бы не сказал, что Илья солидарен. Он может сказать, что у него task есть, то есть сопрограммы.

Можно, конечно, отдельный тип создать, в дополнение к Services.Action... третий уже, да? Мне только непонятно, как это безопасность повысит. Из него точно также, как и из обычного можно всё порушить.


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

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

В tcl/tk сделано даже две отдельных очереди сообщений, и класть события можно в любую из них. Зачем именно их две - я точно не помню. Можно попробовать начать отсюда.


https://wiki.tcl-lang.org/page/event+loop

https://wiki.tcl-lang.org/page/update

https://wiki.tcl-lang.org/page/Update+c ... ed+harmful



Чтобы нельзя было от этого опыта отмахнуться, отмечу, что tcl/tk весьма интенсивно используется в UI в автоматизации, где проблема "кот сел на мышь" должна рассматриваться.

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


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

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
P.S. да, такие "внутренние циклы обработки событий" тоже допустимы, но они должны периодически пропускать события из очереди, т.е. я не совсем правду написал про разбивку на все мельчайшие события. Циклы и работа на стеке допустимы, но в любом случае нужно часто читать из очереди, соблюдать свой приоритет и быть готовым к исчезновению почвы под ногами. В tcl/tk такие вложенные циклы есть, и есть update, к-рый обрабатывает очередь.


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
В патче (от Александра Ильина. кажется), когда Services.Loop вызывается из цикла мыши, никакой многопоточности не возникает, это всё однопоточно и безопасно.
Рисков рекурсии (что из Action снова долетит на Ports.Input) - тоже нет.

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


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

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Борис Рюмшин писал(а):
Можно, конечно, отдельный тип создать, в дополнение к Services.Action... третий уже, да? Мне только непонятно, как это безопасность повысит. Из него точно также, как и из обычного можно всё порушить.

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

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

Есть, как я понял, несколько реализаций сопрограмм в ББ, в т.ч. у меня своя, основанная на действиях Services.Action. Последняя рассчитана на то, что действие начинает работу на "пустом" стеке, т.е. Do вызывается из главной петли, а не из HostPorts.Input.
Но сопрограммы принципиально не решают проблему с котом. Вот тов. Шариков проблему с котом решал иначе: "Мы их душили-душили, душили-душили..."


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

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Илья Ермаков писал(а):
В патче (от Александра Ильина. кажется),

А где посмотреть?


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Илья Ермаков писал(а):
... Ну, будет отдельный тип - а как его крутить, когда мышь захватила цикл? Точно так же (а как ещё).

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


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Борис Рюмшин писал(а):
Можно, конечно, отдельный тип создать, в дополнение к Services.Action... третий уже, да? Мне только непонятно, как это безопасность повысит. Из него точно также, как и из обычного можно всё порушить.

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


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
budden писал(а):
В tcl/tk сделано даже две отдельных очереди сообщений, и класть события можно в любую из них. Зачем именно их две - я точно не помню. Можно попробовать начать отсюда.

Тут у нас получается очередь остаётся одна. Но во время захвата мыши из очереди будут браться к выполнению только события, которые были в неё добавлены особой процедурой или имеют отдельный тип.


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

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Ну тут возникает у меня вопрос, а что такого священного в этой мыши? Почему её обработчик столь приоритетен, что блокирует часть функционала и позволяет только какое-то выделенное подмножество? Это, конечно, вопрос, который имеет смысл рассматривать не "вообще", а в контексте конкретной программы, но всё же.


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Вот тут расширенное обсуждение проблемы с упоминанием и патча Александра Ильина.
https://forum.blackboxframework.org/vie ... f=50&t=393
Там Хельмут приводит переписку Ильи и Марко из списка рассылки. Йозеф приводит свою переписку с Марко также.

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

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


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

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
Иван Денисов писал(а):
Суть в том, чтобы не оказалось, что пользователь нажал на какую-то часть отображения, которая уже вообще не в том месте из-за отложенных действий. Вот так. Например, крутится шарик, надо его мышкой поймать. А за время пока пользователь жал на этот шарик, шарик уже переместился в другое место. Поэтому в Блэкбоксе по умолчанию действия во время трекинга мыши замирают.
Хм... Тогда здесь проблема в удалении "модельного времени" из системы. Потому, что в однозадачной среде - как-то нужно сильно алгоритмически постараться, чтобы возникла, описанная Вами, ситуация с шариком.
Получается, что:
1) ... с одной стороны, мы ПОНИМАЕМ, что работаем в строго однозадачной исполняющей системе
2) ... с другой, - совершенно этот факт игнорируем и, при моделировании "параллельной работы", из задачи, ПОЧЕМУ-ТО, исключены "моменты переключения" и "моделирования сохранения контекста" с разгребанием распознавания условий продолжения выполнения или откладывания исполнения при невыполнении неких условий.


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

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Wlad, я не очень понял, что Вы написали, можно поподробнее про переключение? Насчёт однозадачности я не соглашусь. Системы, основанные на обработке событий, логически не являются однозадачными. Параллельность обеспечивается за счёт очереди событий и за счёт цепочек сообщений, на которые разбивается каждая отдельная задача.

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

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

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

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


Последний раз редактировалось budden Вторник, 05 Октябрь, 2021 10:54, всего редактировалось 2 раз(а).

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

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

Но в целом идею понял - соглашусь с ней.

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


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

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


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

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


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

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


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

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