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