OberonCore
https://forum.oberoncore.ru/

Потоки и обработка собщений в BlackBox
https://forum.oberoncore.ru/viewtopic.php?f=31&t=367		 Страница 2 из 2
Автор:  Штирлиц [ Среда, 24 Январь, 2007 10:50 ]
Заголовок сообщения: 
Сергей Губанов писал(а):
Чего-то тут не многопоточность обсуждается, а оконная подсистема. Надо в другую ветку форума перемещаться...

Цитата:
когда мышь отпущена


Мышь может быть нажата на одном окне, а отпущена уже на другом. То есть окно на котором мышь была нажата, сообщения об отпускании нажатой кнопки может и не получить.


Если для окна на WM_LBUTTONDOWN вызвана GetCapture
то и WM_LBUTTONUP окно получит, где-бы не была отпущена клавиша мыши.

P.S. Здесь обсуждается очередь сообщений в контексте многопоточности.
Автор:  Александр Ильин [ Среда, 24 Январь, 2007 17:00 ]
Заголовок сообщения: 
Штирлиц писал(а):
Сергей Губанов писал(а):
Чего-то тут не многопоточность обсуждается, а оконная подсистема. Надо в другую ветку форума перемещаться...

P.S. Здесь обсуждается очередь сообщений в контексте многопоточности.

Сергей прав, не надо связывать все колготки в один узел. Многопоточность - это одно, а проблемы фреймворка с его не во всех местах очень хорошей обработкой сообщений - другое. Предлагаю переместиться в тему "BlackBox Framework/Проблема Ports.Rider.Input".
Автор:  Штирлиц [ Среда, 24 Январь, 2007 18:25 ]
Заголовок сообщения: 
Александр Ильин писал(а):
Штирлиц писал(а):
Сергей Губанов писал(а):
Чего-то тут не многопоточность обсуждается, а оконная подсистема. Надо в другую ветку форума перемещаться...

P.S. Здесь обсуждается очередь сообщений в контексте многопоточности.

Сергей прав, не надо связывать все колготки в один узел. Многопоточность - это одно, а проблемы фреймворка с его не во всех местах очень хорошей обработкой сообщений - другое. Предлагаю переместиться в тему "BlackBox Framework/Проблема Ports.Rider.Input".


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

P.S. Я как-то не хочу что-бы что-то замирало в приложении только потому, что пользователь нажал на кнопку мыши (или нажали кнопку alt и случайно попал в меню) и не отпускает. Не хочу чтобы грузился процессор на 100%, как-будто мышь при этом начала производить сложнейшую вычислительную работу.
:D .
Автор:  Александр Ильин [ Среда, 24 Январь, 2007 22:10 ]
Заголовок сообщения: 
Штирлиц писал(а):
Я не путаю многопоточность и проблемы фреймворка. Просто когда работает поток наступает момент когда он с этим самым фреймворком должен как-то взаимодействовать. И если это взаимодействие оформлено не совсем хорошо, то эту проблему нельзя решать фреймворк отдельно, а активные процедуры отдельно.
Надо решать это совместно. И почему немного не доработать
фреймворк? Тогда было-бы просто все замечательно.

P.S. Я как-то не хочу что-бы что-то замирало в приложении только потому, что пользователь нажал на кнопку мыши (или нажали кнопку alt и случайно попал в меню) и не отпускает. Не хочу чтобы грузился процессор на 100%, как-будто мышь при этом начала производить сложнейшую вычислительную работу.
:D .

Простите, но все же пуатете. Наверное потому, что хотите реализовать синхронизацию через сообщения по аналогии с Delphi VCL. Но ведь это лишь один из способов, не единственный.
Что касается проблем, перечисленных вами в посткриптуме, то они относительно давно решены, и ссылку на патчи я вам дал. Проблема фоновой перерисовки не была решена, поскольку я не считал ее существенной.
Да, фреймворк просится в доработку, но все же это задача, не связанная с многопоточностью. Синхронизацию потоков с фреймворком можно сделать без изменений в логике обработки сообщений, например, по аналогии с патчем фоновой многозадачности.
Автор:  Trurl [ Четверг, 25 Январь, 2007 09:06 ]
Заголовок сообщения: 
Штирлиц писал(а):
P.S. Я как-то не хочу что-бы что-то замирало в приложении только потому, что пользователь нажал на кнопку мыши (или нажали кнопку alt и случайно попал в меню) и не отпускает.

Зависит от приложения. Вон в ворде все замирает и никто не жалуется.

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

А вот это меня совсем не заботит. ;)
Автор:  Штирлиц [ Четверг, 25 Январь, 2007 11:34 ]
Заголовок сообщения: 
Trurl писал(а):
Штирлиц писал(а):
P.S. Я как-то не хочу что-бы что-то замирало в приложении только потому, что пользователь нажал на кнопку мыши (или нажали кнопку alt и случайно попал в меню) и не отпускает.

Зависит от приложения. Вон в ворде все замирает и никто не жалуется.

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

А вот это меня совсем не заботит. ;)


Ну, если Вас это не заботит, тогда вы относитесь к тому типу программистов, которые пишут программы 2+2 = 4. А потом
говорят заказчику, что-то моя программа не пошла на Вашем компьютере. Купите какой-нибудь 4-х процессорный сервак с 4Гб памяти, а еще лучше майнфрейм. Вот тогда она заработает.:)
Автор:  Илья Ермаков [ Четверг, 25 Январь, 2007 12:33 ]
Заголовок сообщения: 
Решение со Sleep(0) внутри HostPorts.Input решает основную проблему - процессор не грузится, и другие потоки не тормозятся.
Александр прав - Input должен выполняться как непрерываемая операция, иначе получим букет побочных проблем.

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

Взаимодействие должно быть косвенным, поток меняет модель - т.е. данные. Отображение периодически отрисовывает эти данные. Сигнал на периодическое обновление подается через Services.Action.
Т.е. GUI и потоки обработки данных взаимодействуют только через общие объекты данных - модели, защищенные, само собой, эксклюзивными блоками, а синхронизироваться по действиям они не должны - GUI по определению на несколько порядков медленнее любых других операций, и ждать главный поток из быстрых потоков без необходимости нельзя.
Страница 2 из 2 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/