Не знаю как сейчас, а во времена дисководов запрет прерываний на длительное время - неизбежность при работе любой оси. Соответственно, дохнут часы, музыка, опрос клавиатуры. Никуда от этого не денешься.Сообщение от alone
Все равно, релокация программ не является критичной функцией системы. Она может подождать. Пока система ждет, что какая-нибудь программа позволит себя релоцировать, она может выполнять эту и другие программы, то есть эффективный прогресс работы ОС будет продолжаться.
При снятии задачи ничего срочно релоцировать не надо - память и ресурсы только освобождаются. Негативно на работе остающихся задач это не сказывается, а консолидация памяти может подождать.
При запуске новой задачи релокация может потребоваться только если фрагментация памяти не позволяет выделить достаточно непрерывных кусков для новой задачи. Но это тоже может подождать. Даже на мощных современных компьютерах запуск некоторых программ длится долго, секунды и даже минуты. Тем более в условиях недостатка памяти, когда система начинает свопиться. А ожидание фрагментации как раз и может возникнуть только в ситуации недостатка памяти.
Ситуация облегчается тем, что дефрагментация памяти по необходимости (а не фоновая) не требует обязательно релоцировать конкретную программу. Задача стоит освободить непрерывный блок, где бы он ни находился. Если одновременно работают несколько задач - то даже если одна из них не готова к релокации, то могут быть готовы другие. Их и релоцировать.
---------- Post added at 23:46 ---------- Previous post was at 23:33 ----------
Можно по каждому килобайту таймер проверять и, если прошла секунда - переключаться на системный вызов. Я так делаю в своих программах, где требуется индикация прогресса.
А еще эффективнее - не по килобайту, а по заранее рассчитанному объему работы, который даже на медленных компьютерах не будет выполняться дольше секунды. Тем самым минимизируется количество даже проверок таймера.
Ответить с цитированием