Нет, получить и установить контекст можно только для остановленного потока, т.е. нужен третий ThreadCloneWorkerThread. Или надо запустить поток, в который будут переданы тиды двух потоков, которые будут остановлены, а после восстановлены с самовыпилом третьего потока.
Не спорю, решений можно придумать много. Просто интуитивно ожидаешь, что системные функции отлажены. Вот они, значения всех регистров, получены, меняй на здоровье. Установлены тоже будут системной функцией. Плюс, заголовки/функции есть и под x86, и под 64.
Ага, спасибо. Я изучал PM по русскоязычным учебникам ассемблера, там очень плохо было это описано. Потом уже добрался до англоязычного руководства по 386, но именно этот вопрос тогда уже не интересовал. А сейчас внезапно вспомнил. Писал тогда свою ОС, вспоминаю проект с теплотой.
Это понятно. Перемапить кусок можно. Я задумался над тем, как стыковать с новым буфером — ведь файлмаппинг займет свой адрес, и нет гарантии, что можно получить кусок встык за ним.
Особенность этого аллокатора была в том, что пространство выделяется размером равным степени двойки. Возможно поэтому повелось удваивать пространство при реаллокации.
Я наивно думал, что любой аллокатор стремится оперировать блоками размера степени двойки. Более того, точно знаю, что с некоторыми аллокаторами (например, FastMM для Delphi) затребование блоков именно такого размера уменьшает фрагментацию.
Кроме того не вижу ни одного повода не удваивать его
Размер растет слишком быстро, в итоге получается, что после определенного момента мы для записи лишнего байта будем выделять мегабайты памяти, это неоптимально.
Мне кажется, логичным был бы множитель вроде логарифма от какого-то параметра, т.е. крутой рост в самом начале, когда будет много вызовов и более пологий рост в конце.
То-есть, сегмент, который «растет вниз» действительно растет вниз, от базового адреса в сторону младших, т.е. не last address=base + size, а last address = base-size, так что ли?
В чем суть стратегии «увеличивать вдвое»? Почему именно вдвое? Если неизвестно, какие данные записываются и с какой скоростью, непонятно, какой необходим прирост. Есть ли какие-то изыскания по этой теме?
Раз статья 0, позволю себе немного оффтопный вопрос.
Что будет, если при переходе в защищенный режим загрузить в SS селектор сегмента, который описан как сегмент данных (Бит ED = 0 в байте AR дескриптора, т.е. признак «рост вниз» отключен)? Точнее — я знаю, что ничего не случится, стек будет работать как обычно, но зачем тогда этот бит?
Разве не было бы логично обновить веб-сервер (и не только), чтобы он корректно эскейпил заголовки и прочее непосредственно при передаче в баш?
Веб-сервер отрабатывает корректно. Это bash не проверяет свои входные данные на корректность. Если у вас есть программа с одним окном и одним editboxом, в который пользователь вводит делитель, и при вводе 0 программа выпадает с division by zero, проблема в вашем коде, а не коде графической оболочки, реализующей editbox.
Последовательно расположенными в физической памяти?
Точнее, я имею в виду, system можно ужать почти до нуля, до примерно 1000 строк. SysInit ужимается до 32. SysUtils просто не подключается.
Но отказаться от system уже не так просто. Хотя и можно.
Не спорю, решений можно придумать много. Просто интуитивно ожидаешь, что системные функции отлажены. Вот они, значения всех регистров, получены, меняй на здоровье. Установлены тоже будут системной функцией. Плюс, заголовки/функции есть и под x86, и под 64.
Не говоря об этих флагах:
// CONTEXT_CONTROL specifies SegSs, Rsp, SegCs, Rip, and EFlags.
//
// CONTEXT_INTEGER specifies Rax, Rcx, Rdx, Rbx, Rbp, Rsi, Rdi, and R8-R15.
//
// CONTEXT_SEGMENTS specifies SegDs, SegEs, SegFs, and SegGs.
//
// CONTEXT_DEBUG_REGISTERS specifies Dr0-Dr3 and Dr6-Dr7.
//
// CONTEXT_MMX_REGISTERS specifies the floating point and extended registers
// Mm0/St0-Mm7/St7 and Xmm0-Xmm15).
//
Помню, где-то была статья о helloworld в несколько килобайт.
Зависит от конкретного менеджера памяти.
И я тоже. Странно, что вы мне это пишете.
Значительно меньшую чем при каком выделении?
Все как всегда — нельзя выиграть одновременно в силе и перемещении.
Я наивно думал, что любой аллокатор стремится оперировать блоками размера степени двойки. Более того, точно знаю, что с некоторыми аллокаторами (например, FastMM для Delphi) затребование блоков именно такого размера уменьшает фрагментацию.
Размер растет слишком быстро, в итоге получается, что после определенного момента мы для записи лишнего байта будем выделять мегабайты памяти, это неоптимально.
Мне кажется, логичным был бы множитель вроде логарифма от какого-то параметра, т.е. крутой рост в самом начале, когда будет много вызовов и более пологий рост в конце.
Можно подробнее, что вы имеете в виду, что это даст?
Интересно, как это реализовано в Win32…
Что будет, если при переходе в защищенный режим загрузить в SS селектор сегмента, который описан как сегмент данных (Бит ED = 0 в байте AR дескриптора, т.е. признак «рост вниз» отключен)? Точнее — я знаю, что ничего не случится, стек будет работать как обычно, но зачем тогда этот бит?
Веб-сервер отрабатывает корректно. Это bash не проверяет свои входные данные на корректность. Если у вас есть программа с одним окном и одним editboxом, в который пользователь вводит делитель, и при вводе 0 программа выпадает с division by zero, проблема в вашем коде, а не коде графической оболочки, реализующей editbox.