OberonCore

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

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

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

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


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

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

А как будет строиться выполнение параллельно с циклом мыши?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

P.S. да, такие "внутренние циклы обработки событий" тоже допустимы, но они должны периодически пропускать события из очереди, т.е. я не совсем правду написал про разбивку на все мельчайшие события. Циклы и работа на стеке допустимы, но в любом случае нужно часто читать из очереди, соблюдать свой приоритет и быть готовым к исчезновению почвы под ногами. В tcl/tk такие вложенные циклы есть, и есть update, к-рый обрабатывает очередь.

В патче (от Александра Ильина. кажется), когда Services.Loop вызывается из цикла мыши, никакой многопоточности не возникает, это всё однопоточно и безопасно.
Рисков рекурсии (что из Action снова долетит на Ports.Input) - тоже нет.

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

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

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

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

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

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

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

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

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

Вот тут расширенное обсуждение проблемы с упоминанием и патча Александра Ильина.
https://forum.blackboxframework.org/vie ... f=50&t=393
Там Хельмут приводит переписку Ильи и Марко из списка рассылки. Йозеф приводит свою переписку с Марко также.


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

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

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

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

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

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

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

Ну любые перерисовки запускаются отложенно (Views.Update просто помечает вьюшку как требующую перерисовки).

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

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