ROS Newsletter72

Выпуск новостей ReactOS №72

• Публикация в архиве

Общая информация

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

Сервера, на которых находится хостинг проекта, недавно были перенесены и обновлены, из-за этого сайт ReactOS был некоторое время недоступен. После обновления PHP кое-что оказалось неработоспособно, но этот вопрос был быстро решен. А вот обновление операционной системы на сервере принесло куда больше неприятностей, поэтому веб-сайт, списки рассылки и службы SVN в середине недели были недоступны. Перенос сервера уже почти окончен, и вы можете ощутить улучшения в скорости на сайтах BuildBot, Doxygen и ISO. Кроме того, перенос позволяет абсолютно бесплатно добавить еще одну машину для сборки, что и будет сделано в ближайшее время.

Очередь сообщений

После отправки коммита с исправлением, связанным с обработкой сообщений в ReactOS Михаэлю Мартину (Michael Martin) удалось устранить ряд ошибок. Приложения Win32 работают в цикле, который получает и обрабатывает сообщения, посылаемые ему от ОС в качестве реакции на взаимодействие с пользователем и системные события. Эти сообщения, по большей части, обрабатываются циклом обработки сообщений, который поддерживает отправку сообщений к процедуре, занимающейся их обработкой в приложении. Существует особый тип сообщений, которые называются "внеочередными сообщениями", они идут в обход как поддерживаемой системой очереди сообщений, так и очереди сообщений конкретного потока, непосредственно направляясь в процедуру обработки сообщений приложения. В ReactOS эти сообщения не рассматривались как внеочередные, и в итоге проходили через цикл обработки сообщений, а не направлялись непосредственно в процедуру обработки сообщений. Михаэль исправил алгоритм работы ROS, и после добавления еще нескольких других исправлений сумел убить шесть ошибок одним коммитом.

Утечка описателей

Во время тестирования Adobe Acrobat 6 Тимо Кройцер (Timo Kreuzer) наткнулся на довольно интересную и очень серьезную ошибку. Для повышения производительности подсистема Win32 пытается отложить ресурсоёмкие переходы в режим ядра, накапливая команды отрисовки, чтобы впоследствии обработать их все вместе, а не делать переключения контекста для каждой них в отдельности. К сожалению, в коде накопления неправильно индексировалась таблица, которая содержала указатели на регионы GDI. Использовавшееся для индексации значение на самом деле представляло собой байтовое смещение в массиве, а не смещение индекса. В результате ОС теряла регионы в накопленных группах и вызывала утечку связанных с ними контекстов. Это, разумеется, приводило к массовой утечке ресурсов, и, из-за других ошибок в подсистеме Win32, в конечном счете обрушивало ОС. Тот факт, что эта проблема могла привести к аварии, на самом деле не был столь очевиден, поскольку весь этот код находился в пользовательском режиме. Для обрушения ОС требуются сбои в режиме ядра, так что где-то ниже по стеку ОС не обрабатывала утечку должным образом.

Когда Тимо решил эту проблему, появилась другая. Если раньше ОС теряла контексты и регионы, то теперь она их преждевременно удаляет. Проблема снова проявилась в Adobe Acrobat 6 и фактически сделала его непригодным к работе благодаря происходившим неправильным отрисовкам. В совокупности эти две проблемы настолько серьезны, что приходится только гадать, почему они не были выявлены ранее. Пока что Тимо отключил эту часть кода накопления до тех пор, пока он не сможет найти причину всего этого.

PnP и UniATA

Когда драйвер UniATA стал драйвером по умолчанию для SATA и PATA дисков, была сделана маленькая ошибка, приводившая к пропуску перечислителя канала по причине того, что драйвер PCIIDE больше не был запущен. В итоге, система Plug And Play не знала о существовании этих каналов и, следовательно, не могла загрузить драйверы для них. Так как эти каналы являются связующим звеном между дисками и остальной частью системы, отсутствие загруженных и работающих драйверов привело бы к невозможности взаимодействия с дисками. Или, по крайней мере, так было бы, если бы система PnP в ReactOS работала правильно. Ирония в том, что из-за несоответствия стека устройств хранения модели PnP вовлечённых в процесс драйверов это не особо волновало. ReactOS просто устанавливала драйвер UniATA и для контроллера диска и для канала, поэтому она работала, но не потому, что она должна была, а потому, что остальная часть стека не знала разницы. Кэмерон Гутман (Cameron Gutman) заметил эту проблему по ходу своей работы над PnP и исправил её, однако видимых последствий от его исправления мало, если они вообще есть. По крайней мере, это поможет облегчить переход к более PnP-совместимому стеку устройств хранения.