информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Сетевые кракеры и правда о деле ЛевинаПортрет посетителя
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / operating systems
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[NT] Реакция на мыша 18.11.04 09:53  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
Такая хронь: при большой загруженности проца ощущаются жуткие тормоза в обработке мышовых евентов(тормозит переключение и перерисовка окон, зависает курсор). Причем, похоже, это не из-за того, что проги несвоевременно брабатываютсообщения, а именно фича системы (т.е., скажем вычисления имеют больший приоритет, чем обработка мышовых событий). При этом, прерывания от мышки обрабатываются правильно: курсор часто "зависает", потом скачком перепрыгивает на новое место.

set priority помогает, но не до конца.

Хотелось бы заставить систему обрабатывать события мыши с наивысшим приоритетом. Т.е. добиться того, чтобы по клику все процессы не связанные с ним останавливались до полной отработки всех вызванных кликом сообщений. Тем более, что сырцы есть. Кто нить копал в этом направлении? Где может сидеть этот затык, ИМХО, в ntoskrnl? Я давно уже сталкивался с такой пакостью, что в ф-циях обработки мутексов на разных уровнях имеются множественные лазейки, позволяющие системе перехватывать и передавать управление.
Как тебе скорее всего известно, прерывание от мыши (да и от... 18.11.04 13:12  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
Как тебе скорее всего известно, прерывание от мыши (да и от прочих) обрабатывается мгновенно, как только приходит. Драйвера чтоб долго не задерживаться в обработчике обычно откладывают исполнение при помощи механизма DPC. Но и тут затыка быть не может, потому как первое, что делает винда при понижении IRQL ниже DPC уровня (в общем когда переходит в состояние, в котором разрешено работать планировщику задач) - это обрабатывает DPC-очередь и только после этого начинает планировать потоки.

Эта DPC процедура завершает обработку прерывания и если, кто то ждет ввода-вывода от данного устройства, то завершает IRP. На завершении IRP затыка тоже быть не может, потому как в ней просто вызываются completion-routine-ы для всего стека устройств (вообще-то не только, но это главное). Самая частая реализация completion-routine-ы предусматривает установку какого либо переданного event-а. Реализация установки event-а тоже не предусматривает тормозов, потому как СРАЗУ будит поток, ожидающий на этом event-е (чаще всего как раз поток, который ставил IRP и стал в ожидание его завершения). То есть при выходе из KeSetEvent, ожидающий поток уже отработал и сделал все что ему надо.

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

В винде чтением мыши/клавы занимается системный поток RawInputThread (RIT). Он читает из устройств мыши/клавы и рассылает сообщения потокам. К сожалению не могу сейчас сказать, какой именно поток занимается ОТРИСОВКОЙ курсора. Но именно ему надо повышать приоритет, чтобы он успевал разгребать свою очередь USER-сообщений
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach