Исправление KivApple, (текущая версия) :
Да. Создать процесс без потоков. Затем выделить и инициализировать память внутри него. Затем запустить первый поток, указав ему точку входа. В чём проблема?
Нужны ровно четыре системных вызова:
- Создание пустого процесса (фактически выделение нескольких килобайт структур, очень быстро)
- Аллокация страниц памяти в другом процессе (из пространства ядра по эффективности можно сделать одинаково с аллокацией памяти в текущем процессе)
- Копирование страниц памяти в другой процесс. Скорее всего не очень эффективно. Можно оптимизировать, разрешив предыдущему вызову не выделять новую физическую память, а забирать указанный блок из текущего процесса, тогда будет очень быстро
- Создание тредов в других процессах. Тут опять всего лишь создание небольшой структуры в пространстве ядра, очень быстро
Двойной профит в том, что с небольшими доработками мы получаем мощные примитивы для отладки (добавить методы для создания точек останова и копирования памяти в обе стороны, а не в одну).
Касательно безопасности, правило простое - дочерний процесс в полном доступе для родительского (во всяком случае, пока не сменит uid).
Никогда не понимал, как fork может быть быстрее подхода выше с учётом того, что он сначала копирует всё, потом освобождает ненужную память, а затем выполняет те же самые операции (выделение и инициализация памяти нового процесса). Разработчики unix не осилили эффективную реализацию удаленного маппинга страниц в чужом процессе? Так fork точно также требует манипуляции чужим адресном пространством. CoW нифига не бесплатен - надо всем страницам проставить флаг RO и ловить кучу page fault потом.
Исправление KivApple, :
Да. Создать процесс без потоков. Затем выделить и инициализировать память внутри него. Затем запустить первый поток, указав ему точку входа. В чём проблема?
Нужны ровно четыре системных вызова:
- Создание пустого процесса (фактически выделение нескольких килобайт структур, очень быстро)
- Аллокация страниц памяти в другом процессе (из пространства ядра по эффективности можно сделать одинаково с аллокацией памяти в текущем процессе)
- Копирование страниц памяти в другой процесс. Скорее всего не очень эффективно. Можно оптимизировать, разрешив предыдущему вызову не выделять новую физическую память, а забирать указанный блок из текущего процесса, тогда будет очень быстро
- Создание тредов в других процессах. Тут опять всего лишь создание небольшой структуры в пространстве ядра, очень быстро
Двойной профит в том, что с небольшими доработками мы получаем мощные примитивы для отладки (добавить методы для создания точек останова и копирования памяти в обе стороны, а не в одну).
Касательно безопасности, правило простое - дочерний процесс в полном доступе для родительского (во всяком случае, пока не сменит uid).
Исходная версия KivApple, :
Да. Создать процесс без потоков. Затем выделить и инициализировать память внутри него. Затем запустить первый поток, указав ему точку входа. В чём проблема?
Нужны ровно четыре системных вызова:
- Создание пустого процесса (фактически выделение нескольких килобайт структур, очень быстро)
- Аллокация памяти в другом процессе (из пространства ядра по эффективности можно сделать одинаково с аллокацией памяти в текущем процессе)
- Копирование памяти в другой процесс. Скорее всего не очень эффективно. Можно оптимизировать, разрешив предыдущему вызову не выделять новую физическую память, а забирать указанный блок из текущего процесса, тогда будет очень быстро
- Создание тредов в других процессах. Тут опять всего лишь создание небольшой структуры в пространстве ядра, очень быстро
Двойной профит в том, что с небольшими доработками мы получаем мощные примитивы для отладки (добавить методы для создания точек останова и копирования памяти в обе стороны, а не в одну).
Касательно безопасности, правило простое - дочерний процесс в полном доступе для родительского (во всяком случае, пока не сменит uid).