Базовый блок заканчивается при инструкции чтения памяти, в вики то же написано. А ведь это почти каждая вторая инструкция. Как это решается.
Даниил, заканчивать базовый блок на инструкции которая может вызвать исключение -- это возможный вариант, но он очень пессимистичный и точно не единственный. В QEMU, например, это не так.
проверка выхода за границы массива…машина эмулирует память, и должна выдавать исключения при выходе за границу памяти.
Ты уж определись, "память" или "массив". Потому что эмулятор должен проверять, что любой доступ к эмулируемой памяти в неё попадает. А что такое "массив" никто кроме компилятора не знает.
Saboteur, вот предлагаю тебе и написать такой ответ. Дополнительные звёздочки почтения за отсылки в код.
Мой ответ на вопрос "какую роль в планировании играют процессы" остаётся прежним -- "несущественную, в первом приближении -- никакую".
переключение между процессами и тредами имеет разную стоимость
Saboteur, правильнее было бы сказать "переключение между потоками одного процесса и между потоками разных процессов имеет разную стоимость", после чего можно вернуться в исходную позицию: планировщик ОС работает с потоками (или, как уточняют по твоей ссылочке, со schedulable entities). Да, в качестве эффекта высшего порядка малости он может учитывать свойства процесса которому принадлежит поток, но это вопрос не того уровня, где в ответе имеют значение подобные мелочи.
В других ОС
В других ОС вообще процессов может не быть, только "задачи".
небольшой пример, как ОС использует этот учет ресурсов?
Sazoks, когда процесс завершается, ОС освобождает всю выделенную им приватную память и закрывает все открытые им файлы. Это происходит потому, что такие ресурсы ассоциированы именно с процессом, а не с чем-нибудь другим.
Dmitrii, спасибо, я знаю. Кроме того, это частный случай. В общем случае выделение пространства на стеке может происходить многократно в течение выполнения функции.
Однако, ещё раз, порядок размещения переменных языка высокого уровня в стеке не связан напрямую с направлением роста стека. Я привёл пример демонстрирующий это.
Правильный ответ на вопрос "почему адреса переменных расположены в таком порядке" -- "потому что так решил компилятор", вон он, ниже.
Это неправильный ответ. Направление роста стека не связано напрямую с тем, как компилятор размещает на нём автоматические переменные. Вот пример, когда адреса не связаны с порядком объявления: https://godbolt.org/z/f6YWeW5s6
Иван Четчасов, другое дело. Можно идти от этого места назад, но гораздо легче идти от точно работающего места вперёд и смотреть, что пошло не так. Последнее точно работающее место в твоём коде было здесь. Можно для начала проверить успешность следующего вызова do_read.
Иван Четчасов, будет конечно, почему нет? Загляни в Intel developers manual, во втором томе, в табличке 2-1. "16-Bit Addressing Forms with the ModR/M Byte" перечислены все возможные форматы адресации реального режима.
Дать разрешения на запись в каталог /var/www/html пользователю от имени которого vsftpd пытается туда писать. Что это за пользователь -- зависит от настроек vsftpd и проведённой аутентификации.
Даниил, заканчивать базовый блок на инструкции которая может вызвать исключение -- это возможный вариант, но он очень пессимистичный и точно не единственный. В QEMU, например, это не так.
Ты уж определись, "память" или "массив". Потому что эмулятор должен проверять, что любой доступ к эмулируемой памяти в неё попадает. А что такое "массив" никто кроме компилятора не знает.