Набор тестов POSIX-функций впервые проходит на многоядерной конфигурации без зависаний

28.02.2026

Набор тестов os-test впервые отработал на нескольких ядрах QEMU без единого зависания. Раньше многопроцессорная конфигурация стабильно выявляла ошибки ядра.

Что такое os-test

Это набор тестов, проверяющих поведение операционной системы на соответствие POSIX: файловые операции, процессы, потоки, сигналы, время. Тесты не проверяют внутренности — только то, что видит программа.

Запуск на одном ядре и на нескольких — разные проверки. Однопоточная конфигурация не создаёт гонок по определению: два потока не могут выполняться одновременно. Многопроцессорная выявляет всё, что связано с одновременным доступом, — а это и есть дефекты самого опасного класса.

Почему зависание — это не «тест не прошёл»

Обычный провал теста — это отказ с кодом возврата: проверка не совпала. Зависание хуже: поток ждёт события, которого не будет, и никто не знает почему. Тест не падает — он перестаёт завершаться.

Поэтому зависания в многопроцессорном режиме обычно и сигнализируют о гонках и взаимных блокировках в ядре, а не об ошибках в логике.

Что пришлось починить

За месяц закрыт ряд ошибок ядра, проявлявшихся именно при нескольких процессорах:

  • гонка при слиянии областей памяти;
  • падение очереди событий прямо во время обработки;
  • потеря адресного пространства при освобождении;
  • переполнение арифметики при проверке времени в nanosleep;
  • упорядоченные блокировки для очереди ожидания и триггера событий.

Последний пункт продолжает работу, начатую в сентябре 2025 года: тогда упорядоченные блокировки появились как способ ловить нарушения порядка на этапе компиляции, и с тех пор их добавляли по мере нахождения новых мест.

Почему это важно для Rust

Многопоточность в Redox — это не «работает на одном ядре». Пока набор тестов зависает на многопроцессорной конфигурации, любой многопоточный код на Rust — лотерея: tokio, rayon, обычные std::thread.

Именно поэтому новость о «тесты прошли» здесь весомее обычной правки ядра: это утверждение о надёжности подсистемы, на которой держится всё остальное.

Оригинал

Сводка «This Month in Redox — February 2026», раздел «Multi-threading Reliability Improvements». Дата — 28 февраля 2026 года: это день последней из закрывающих правок (fix: validate timespec in nanosleep, redox-os/kernel)

Упоминаний: 1 · Просмотров: 2