Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
|
Как тебе скорее всего известно, прерывание от мыши (да и от... 18.11.04 13:12 Число просмотров: 2392
Автор: amirul <Serge> Статус: The Elderman
|
Как тебе скорее всего известно, прерывание от мыши (да и от прочих) обрабатывается мгновенно, как только приходит. Драйвера чтоб долго не задерживаться в обработчике обычно откладывают исполнение при помощи механизма DPC. Но и тут затыка быть не может, потому как первое, что делает винда при понижении IRQL ниже DPC уровня (в общем когда переходит в состояние, в котором разрешено работать планировщику задач) - это обрабатывает DPC-очередь и только после этого начинает планировать потоки.
Эта DPC процедура завершает обработку прерывания и если, кто то ждет ввода-вывода от данного устройства, то завершает IRP. На завершении IRP затыка тоже быть не может, потому как в ней просто вызываются completion-routine-ы для всего стека устройств (вообще-то не только, но это главное). Самая частая реализация completion-routine-ы предусматривает установку какого либо переданного event-а. Реализация установки event-а тоже не предусматривает тормозов, потому как СРАЗУ будит поток, ожидающий на этом event-е (чаще всего как раз поток, который ставил IRP и стал в ожидание его завершения). То есть при выходе из KeSetEvent, ожидающий поток уже отработал и сделал все что ему надо.
Все. Ввод-вывод практически без тормозов доставлен от прерывания ожидающему потоку. Дальше тормоза могут быть в самом этом потоке.
В винде чтением мыши/клавы занимается системный поток RawInputThread (RIT). Он читает из устройств мыши/клавы и рассылает сообщения потокам. К сожалению не могу сейчас сказать, какой именно поток занимается ОТРИСОВКОЙ курсора. Но именно ему надо повышать приоритет, чтобы он успевал разгребать свою очередь USER-сообщений
|
|
<operating systems>
|
[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-сообщений
|
|
|
подробно о проекте
Анализ криптографических сетевых...
