Здравствуйте, Roman Odaisky, Вы писали:
RO>Много думал, но не понял, как в ОС, исполняющих только верифицированный код, можно реализовать IPC, соблюдая изоляцию процессов.
RO>Предположим, у нас есть ОС, представляющая собой Java-машину, умеющую исполнять только байткод Java. Вследствие того, что в Java строгая типизация, нет reinterpret_cast и прочих подобных хаков, каждый процесс получает указатели только из одного источника — из оператора new, соответственно, доступ в чужую память невозможен. Это снимает требование аппаратной защиты памяти и вообще звучит привлекательно. Вот только как реализовать IPC? Если у одного процесса есть большой кусок данных, и он хочет предоставить его другому для обработки, то он с помощью какого-нибудь системного вызова передает указатель, чтобы второй процесс смог получить доступ к данным. Однако что, если в том блоке есть указатели куда-то внутрь адресного пространства первого процесса? При отсутствии аппаратной защиты памяти второй процесс, нарушая принцип минимальных привилегий, сможет влезть куда не просят.
Проксировать доступ или передавать сериализованные копии.
RO>И еще, если на каждый байт памяти могут быть указатели из скольки угодно процессов, как это скажется на GC?
GC должен быть общий для них. Сомневаюсь, что это есть где-то кроме AS/400.
Здравствуйте, Serginio1, Вы писали:
.>>Было бы интересно рассмотреть возможность переноса объектов из одного пространства в другое без копирования, а просто поменяв некий дескриптор у объекта, что позволит сохранить инвариант. S> Кто будет следить за временем жизни.
Виртуальная машина которая в данном случае неотделима от ОС.
S>Да и насколько эти сложности перенесут больше бенефита перед копирования или ремотинга?
Большие.
Ты что думаешь копирование бесплатно?
S> Меж процесное взаимодействие не краеугольный камень.
Он самый.
Ибо если делать по уму то нужно ликвидировать потоки и оставить только процессы.
Причем сделать их и их взаимодействие максимально легкими.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Roman Odaisky, Вы писали:
RO>Много думал, но не понял, как в ОС, исполняющих только верифицированный код, можно реализовать IPC, соблюдая изоляцию процессов.
Тут и думать не надо. Проблемы нет как таковой, то есть она лишь в постановке задачи.
Если ОС следит за памятью и запуском GC, то у нас один GC на все процессы, и никаких проблем с передачей указателей нет.
Но если ты передал указатель в другой процесс — то у тебя уже нет изоляции процессов.
Если же ты не передаёшь указатели, а только данные — то изоляция есть. Копировать данные тоже нет нужды, так как их можно ложить в разделяемую область памяти, как и в обычном IPC. За содержимое разделяемой памяти отвечает единый GC единой ОС.
Здравствуйте, Mazay, Вы писали:
M>Ээээээ.... . Вы меня таки уличили в незнании терминов. Как я понимаю процесс == task == N потоков + данные,
Термин task присутствовал в Win16 и был официально исключен MS при переходе к Win32. В остальном верно.
>поток == thread.
Да
>Что такое job?
A job object allows groups of processes to be managed as a unit. Job objects are namable, securable, sharable objects that control attributes of the processes associated with them. Operations performed on the job object affect all processes associated with the job object.
Много думал, но не понял, как в ОС, исполняющих только верифицированный код, можно реализовать IPC, соблюдая изоляцию процессов.
Предположим, у нас есть ОС, представляющая собой Java-машину, умеющую исполнять только байткод Java. Вследствие того, что в Java строгая типизация, нет reinterpret_cast и прочих подобных хаков, каждый процесс получает указатели только из одного источника — из оператора new, соответственно, доступ в чужую память невозможен. Это снимает требование аппаратной защиты памяти и вообще звучит привлекательно. Вот только как реализовать IPC? Если у одного процесса есть большой кусок данных, и он хочет предоставить его другому для обработки, то он с помощью какого-нибудь системного вызова передает указатель, чтобы второй процесс смог получить доступ к данным. Однако что, если в том блоке есть указатели куда-то внутрь адресного пространства первого процесса? При отсутствии аппаратной защиты памяти второй процесс, нарушая принцип минимальных привилегий, сможет влезть куда не просят.
В традиционных системах эта задача решается тривиально, даже без копирования данных между процессами (разделяемая память, splice(2)/vmsplice(2) и т. д.). А вот как в ОС с защитой памяти, основанной на строгой типизации, можно передать объект из процесса в процесс (особенно без копирования) так, чтобы сохранить изоляцию процессов, — в общем случае, когда объект может содержать указатели на данные, которые передавать нельзя?
И еще, если на каждый байт памяти могут быть указатели из скольки угодно процессов, как это скажется на GC?
Здравствуйте, Roman Odaisky, Вы писали:
RO>Много думал, но не понял, как в ОС, исполняющих только верифицированный код, можно реализовать IPC, соблюдая изоляцию процессов.
Посмотри http://rsdn.ru/article/singularity/singularity.xml
Roman Odaisky wrote:
> А как можно обойтись без копирования?
Да как я понимаю, это теоретически невозможно. Жил-был у тебя граф объектный, раскиданный по всей памяти и вдруг выяснилось что его в другой процесс высылают. Нужно очень осторожно пройтись по ссылкам и выяснить что можно отдавать, а что нельзя, собрать в единый кусок и передать, либо каждому объекту приписывать токены, кому он виден, что скорее всего нехорошо скажется на производительности.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Roman Odaisky, Вы писали:
RO>Это явно лишнее копирование.
RO>Например, ситуация: надо расшифровать полученные по сети данные, чем занимается отдельный процесс, имеющий доступ к ключам, но ни к чему более. В традиционных ОС можно отображать туда-сюда страницы памяти, на которых записаны данные, и без копирования перекидывать их между процессами, сохраняя безопасность остальных данных. Как что-либо подобное можно было бы сделать в «управляемых ОС»?
Ну создать в памяти файлик, куда бы возможность чтения/записи имели два процесса. Где лишнее копирование?
Ну а вообще любую память можно рассматривать как массив байт. Конечно, лишние проверки и необходимость хранить индексы вместо прямых указателей делает этот путь менее производительным и более геморройным в программировании, но позволяет показать эквивалентность между верифицированным кодом и обычным.
S>>Главное решение в дизайне – инвариант независимости памяти: указатели между объектными пространствами указывают только на Exchange Heap. В частности, ядро не имеет указателей на объектное пространство процесса, и ни один процесс не имеет указателя на объекты другого процесса. Это гарантирует, что каждый процесс может подвергнуться сборке мусора и быть выгруженным без взаимодействия с другими процессами.
RO>Тогда zero copy не выйдет.
можно получить сколь угодно близкое приближение к нему даже при необходимости копирования между процессами.
Называется "ленивый порядок вычислений".
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Roman Odaisky, Вы писали:
RO>Много думал, но не понял, как в ОС, исполняющих только верифицированный код, можно реализовать IPC, соблюдая изоляцию процессов.
Дело не столько в верифицированном коде, сколько в том, что у процесса должно быть свое адресное пространство. В неверифицируемом коде нормального способа расшарить данные тоже не существует. То что есть возможность отдать кусок данных из своего адресного пространства через splice(2)/vmsplice(2) не сильно спасает, так как если у тебя есть граф раскинувшийся по всему адресному пространству если передавать его через splice(2)/vmsplice(2), то указатели все равно окажутся невалидными. Если же с самого начала работать в расшаренном куске данных, использую вместо указателей смещения в пределах этого куска, то это ничем не будет отличаться от уже названного memory-mapped файла.
И вообще, если два процесса разделяют общие данные, то это уже не два процесса, а два потока одного процесса.
Здравствуйте, Pavel Dvorkin, Вы писали:
M>>Нельзя передавать указатели на свою память, это нарушит изоляцию процессов. Указатели на разделяемую память — сколько угодно.
PD>Категорически нет. Адреса разделяемой памяти в разных процессах различны, по крайней мере в Windows линии NT. Вот в 9x можно
Речь же идёт о некоей гипотетической ОС, которая сама вся из себя верифицируемая. Как эту ОС напишешь — так и будет.
Здравствуйте, Serginio1, Вы писали:
WH>>Тут вообще каша. Ничего не понял. WH>>С тобой очень трудно разговаривать. WH>>Выражайся яснее. S> Для имутабельных про
Это называется ясно выразился
S> Ресурсы это Файлы, каналы, итд.
Какие еще файлы? Какое еще итд?
Есть только каналы.
S>что при выгрузки процесса должно закрыться, а значит не должно иметь прямых ссылок из других процессов.
Упоминание про uniqueness типы ты конечно не заметил.
Так вот типы концов канала uniqueness типы.
S>А также мутабельные объекты должны храниться в куче процесса.
И будут. В чем проблема?
S> Только кучи должны быть разными для разделяемых и неразделяемых объетов.
Так и будут. В чем проблема?
Примитивное решение просто смотреть на типы.
Более сложное но и более эффективное статически анализировать жизнь объектов и те которые гарантированно не покинут процесс хранить локально.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
«Инвариант Exchange Heap в том, что она не содержит никаких указателей на GC-кучу какого либо процесса. Таким образом, тип R должен быть обмениваемым типом, то есть примитивным value-типом (int, char и т.д.), перечислением или простой структурой с полями обмениваемых типов.»
Т. е., связный список передать уже не выйдет? (Хотя и в традиционных ОС это было бы затруднительно.)
Здравствуйте, Roman Odaisky, Вы писали:
RO>Много думал, но не понял, как в ОС, исполняющих только верифицированный код, можно реализовать IPC, соблюдая изоляцию процессов.
А просто файл создать в памяти нельзя? Или верифицированный код не может работать с файлами?
Здравствуйте, Roman Odaisky, Вы писали:
RO>Т. е., связный список передать уже не выйдет? (Хотя и в традиционных ОС это было бы затруднительно.)
Если только список на массиве.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Mystic, Вы писали:
RO>>Много думал, но не понял, как в ОС, исполняющих только верифицированный код, можно реализовать IPC, соблюдая изоляцию процессов. M>А просто файл создать в памяти нельзя? Или верифицированный код не может работать с файлами?
Это явно лишнее копирование.
Например, ситуация: надо расшифровать полученные по сети данные, чем занимается отдельный процесс, имеющий доступ к ключам, но ни к чему более. В традиционных ОС можно отображать туда-сюда страницы памяти, на которых записаны данные, и без копирования перекидывать их между процессами, сохраняя безопасность остальных данных. Как что-либо подобное можно было бы сделать в «управляемых ОС»?
Roman Odaisky wrote:
> Например, ситуация: надо расшифровать полученные по сети данные, чем > занимается отдельный процесс, имеющий доступ к ключам, но ни к чему > более. В традиционных ОС можно отображать туда-сюда страницы памяти, на > которых записаны данные, и без копирования перекидывать их между > процессами, сохраняя безопасность остальных данных. Как что-либо > подобное можно было бы сделать в «управляемых ОС»?
Так тут просто — кидаться массивами byte.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>Да как я понимаю, это теоретически невозможно.
Вот и меня это всё смущает. Получается какая-то очень полярная система: данные или видимы и к ним есть полный доступ, или вообще невидимы. Хотя... А если передавать, к примеру, const-объекты? Если код верифицирован, то обойти ограничения, накладываемые const, невозможно. Может, можно аналогичным образом реализовать систему прав доступа на уровне языка программирования? const же имеет нулевой оверхед, может, можно изобрести аналогичное языковое средство, и кастовать struct { int const x; int y; } * в struct { int const x; int invisible y; } * — что с этим может сделать злонамеренный код, не имея аналога const_cast? (Да, я знаю, что нельзя преобразовывать X** в X const**, но для Java-подобных языков, где указатели не перенацеливаются, это неактуально.)
Здравствуйте, mkizub, Вы писали:
M>Но если ты передал указатель в другой процесс — то у тебя уже нет изоляции процессов. M>Если же ты не передаёшь указатели, а только данные — то изоляция есть.
Так а если надо передавать нечто сложнее byte[]? Связный список, например?
M>Копировать данные тоже нет нужды, так как их можно ложить в разделяемую область памяти, как и в обычном IPC.
А зачем разделяемая память в такой ОС, если можно выдать наружу указатель на любой кусок своей памяти?
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, mkizub, Вы писали:
M>>Но если ты передал указатель в другой процесс — то у тебя уже нет изоляции процессов. M>>Если же ты не передаёшь указатели, а только данные — то изоляция есть.
RO>Так а если надо передавать нечто сложнее byte[]? Связный список, например?
Нельзя передавать указатели на свою память, это нарушит изоляцию процессов. Указатели на разделяемую память — сколько угодно.
M>>Копировать данные тоже нет нужды, так как их можно ложить в разделяемую область памяти, как и в обычном IPC.
RO>А зачем разделяемая память в такой ОС, если можно выдать наружу указатель на любой кусок своей памяти?
Для изоляции процессов. Если она тебя не волнует — передавай без разделяемой памяти.
Mystic wrote:
> Ну создать в памяти файлик, куда бы возможность чтения/записи имели два > процесса. Где лишнее копирование?
Так это тривиально. Если заранее знать какие данные будут шариться, то их можно сразу делать как "тип R должен быть обмениваемым типом" и тогда пожалуйста. Но всё равно — копирование будет — данные пришли от пользователя как обычный String на куче, а его нужно поместить в тот самый файлик, либо в "тип R".
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Roman Odaisky wrote:
> Вот и меня это всё смущает. Получается какая-то очень полярная система: > данные или видимы и к ним есть полный доступ, или вообще невидимы. > Хотя... А если передавать, к примеру, const-объекты? Если код
Может быть... в общем в сторону передачи строго RO-объектов стоит подумать. Получится erlang?
> верифицирован, то обойти ограничения, накладываемые const, невозможно. > Может, можно аналогичным образом реализовать систему прав доступа на > уровне языка программирования? const же имеет нулевой оверхед, может, > можно изобрести аналогичное языковое средство, и кастовать struct { int > const x; int y; } * в struct { int const x; int invisible y; } * — что с > этим может сделать злонамеренный код, не имея аналога const_cast? (Да, я > знаю, что нельзя преобразовывать X** в X const**, но для Java-подобных > языков, где указатели не перенацеливаются, это неактуально.)
Что произойдёт со ссылками на другие объекты? struct {AnotherStructWithPassword const secretInfo;} ?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>Может быть... в общем в сторону передачи строго RO-объектов стоит подумать. Получится erlang?
А кто за ними будет смотреть? GC только на процесс.
Главное решение в дизайне – инвариант независимости памяти: указатели между объектными пространствами указывают только на Exchange Heap. В частности, ядро не имеет указателей на объектное пространство процесса, и ни один процесс не имеет указателя на объекты другого процесса. Это гарантирует, что каждый процесс может подвергнуться сборке мусора и быть выгруженным без взаимодействия с другими процессами.
Exchange Heap отвечает в Singularity за эффективность коммуникаций, хранит данные, передаваемые между процессами (рисунок 2). Exchange Heap не подвергается сборке мусора, вместо этого используется подсчет ссылок для отслеживания использования блоков памяти, называемых регионами (regions). Процессы имеют доступ к региону через структуру allocation.
Структуры allocation также находятся в Exchange Heap, что позволяет передавать их между процессами, но каждая из них принадлежит в любой момент времени только одному процессу, который и может обращаться к ней. Нижележащий регион доступен только для чтения через несколько allocation. Кроме того, allocation могут иметь различную основу и границы, обеспечивающие различные представления нижележащих данных. Например, протокол, обрабатывающий код в сетевом стеке, может удалить из пакета инкапсулированные заголовки протокола, не копируя их. Регион отслеживает число allocation, указывающих на него, и освобождается, когда количество ссылок падает до нуля. Компилятор Singularity скрывает лишний уровень косвенности, предоставляя строго типизированную ссылку на регион и автоматически генерируя код, скрывающий подробности.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
.>>Может быть... в общем в сторону передачи строго RO-объектов стоит подумать. Получится erlang? ;) S>А кто за ними будет смотреть? GC только на процесс.
S>
S>Главное решение в дизайне – инвариант независимости памяти: указатели между объектными пространствами указывают только на Exchange Heap. В частности, ядро не имеет указателей на объектное пространство процесса, и ни один процесс не имеет указателя на объекты другого процесса. Это гарантирует, что каждый процесс может подвергнуться сборке мусора и быть выгруженным без взаимодействия с другими процессами.
RO>«Инвариант Exchange Heap в том, что она не содержит никаких указателей на GC-кучу какого либо процесса. Таким образом, тип R должен быть обмениваемым типом, то есть примитивным value-типом (int, char и т.д.), перечислением или простой структурой с полями обмениваемых типов.»
RO>Т. е., связный список передать уже не выйдет? (Хотя и в традиционных ОС это было бы затруднительно.)
Убери identity — указатели, — оставь только значения и у тебя всё получится.
(это умолчание Erlang и Haskell, только у Хаскеля больше вариантов, поскольку Erlang вынужден всё копировать при передаче вне VM)
Значение (Maybe ("Hi!",[1,2,3,4,5])) будет значением (Maybe ("Hi!",[1,2,3,4,5])) внутри любого процесса.
Хочешь — копируй целиком. Хочешь — передавай по частям. А хочешь — можешь поделить между процессами.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, Mystic, Вы писали:
RO>>>Много думал, но не понял, как в ОС, исполняющих только верифицированный код, можно реализовать IPC, соблюдая изоляцию процессов. M>>А просто файл создать в памяти нельзя? Или верифицированный код не может работать с файлами?
RO>Это явно лишнее копирование.
RO>Например, ситуация: надо расшифровать полученные по сети данные, чем занимается отдельный процесс, имеющий доступ к ключам, но ни к чему более. В традиционных ОС можно отображать туда-сюда страницы памяти, на которых записаны данные, и без копирования перекидывать их между процессами, сохраняя безопасность остальных данных. Как что-либо подобное можно было бы сделать в «управляемых ОС»?
-- в MVAr i мы пишем данные для процесса, из MVar o читаем.data ProcChan i o = ProcChan (MVar i) (MVar o)
exchange :: ProcChan i o -> i -> IO o
exchange (ProcChan imv omv) i = ...
...
mkCryptProc :: IO (ProcChan (Credentials,Ciphertext))
...
decrypt cryptProcC cert ciphertext = do
plaintext <- exchange (certLeastDisclosureCredentials cert, ciphertext)
return plaintext
...
f = do
...
cryptProcC <- mkCryptProc -- запускает слушателя cryptProcC
...
g cryptProcC
...
g cryptProcC = do
... incomingData ... ...
decrypted <- decrypt cryptProcC (certificate incomingData)
(encryptedBlocks incomingData)
Нот а ток!
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Serginio1 wrote:
> Главное решение в дизайне – инвариант независимости памяти: > указатели между объектными пространствами указывают только на > Exchange Heap. В частности, ядро не имеет указателей на объектное > пространство процесса, и ни один процесс не имеет указателя на > объекты другого процесса. Это гарантирует, что каждый процесс может > подвергнуться сборке мусора и быть выгруженным без взаимодействия с > другими процессами.
Было бы интересно рассмотреть возможность переноса объектов из одного пространства в другое без копирования, а просто поменяв некий дескриптор у объекта, что позволит сохранить инвариант.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Roman Odaisky, Вы писали:
RO>Предположим, у нас есть ОС, представляющая собой Java-машину, умеющую исполнять только байткод Java. Вследствие того, что в Java строгая типизация, нет reinterpret_cast и прочих подобных хаков, каждый процесс получает указатели только из одного источника — из оператора new, соответственно, доступ в чужую память невозможен. Это снимает требование аппаратной защиты памяти и вообще звучит привлекательно. Вот только как реализовать IPC? Если у одного процесса есть большой кусок данных, и он хочет предоставить его другому для обработки, то он с помощью какого-нибудь системного вызова передает указатель, чтобы второй процесс смог получить доступ к данным. Однако что, если в том блоке есть указатели куда-то внутрь адресного пространства первого процесса? При отсутствии аппаратной защиты памяти второй процесс, нарушая принцип минимальных привилегий, сможет влезть куда не просят.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Много думал, но не понял, как в ОС, исполняющих только верифицированный код, можно реализовать IPC, соблюдая изоляцию процессов.
Да как нефиг делать.
RO>Предположим, у нас есть ОС, представляющая собой Java-машину, умеющую исполнять только байткод Java.
На основе ВМ уровня жабы могут быть только экспериментальные поделки.
Ибо система типов жабы настолько убога что ей проверить почти ничего нельзя.
Нужна система типов уровня agda. Вот на ней уже можно сделать что-то практичное.
RO>Вот только как реализовать IPC? Если у одного процесса есть большой кусок данных, и он хочет предоставить его другому для обработки, то он с помощью какого-нибудь системного вызова передает указатель, чтобы второй процесс смог получить доступ к данным. Однако что, если в том блоке есть указатели куда-то внутрь адресного пространства первого процесса? При отсутствии аппаратной защиты памяти второй процесс, нарушая принцип минимальных привилегий, сможет влезть куда не просят.
Тут два варианта.
1)Неизменяемые типы данных.
Можно передавать между процессами сколько угодно и ни кто ни куда не влезет.
2)uniqueness типы. Это такие типы на объекты которых может быть только одна ссылка.
А раз есть только одна ссылка то тоже никто и ничего не сделает.
RO>В традиционных системах эта задача решается тривиально, даже без копирования данных между процессами (разделяемая память, splice(2)/vmsplice(2) и т. д.).
Тривиально аж дальше некуда
RO>И еще, если на каждый байт памяти могут быть указатели из скольки угодно процессов,
На каждый не может.
Это тебе не С++ где можно на середину объекта ссылаться.
RO>как это скажется на GC?
Никак.
Особенно если учесть что GC для неизменяемой кучи гораздо проще и может срезать кучу углов вплоть до сведения ГЦ паузы к вызову барьера памяти.
А если еще учесть что region inference тоже никто не отменял...
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, ., Вы писали:
.>Было бы интересно рассмотреть возможность переноса объектов из одного пространства в другое без копирования, а просто поменяв некий дескриптор у объекта, что позволит сохранить инвариант.
Кто будет следить за временем жизни. Да и насколько эти сложности перенесут больше бенефита перед копирования или ремотинга?
Меж процесное взаимодействие не краеугольный камень.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Serginio1, Вы писали:
.>>>Было бы интересно рассмотреть возможность переноса объектов из одного пространства в другое без копирования, а просто поменяв некий дескриптор у объекта, что позволит сохранить инвариант. S>> Кто будет следить за временем жизни. WH>Виртуальная машина которая в данном случае неотделима от ОС.
Кто то совсем недавно по поводу Оберона, с его общей памятью ворчал? S>>Да и насколько эти сложности перенесут больше бенефита перед копирования или ремотинга? WH>Большие. WH>Ты что думаешь копирование бесплатно?
Копирование со скоростью 6-9 гб/с, дорого но не критично. S>> Меж процесное взаимодействие не краеугольный камень. WH>Он самый. WH>Ибо если делать по уму то нужно ликвидировать потоки и оставить только процессы. WH>Причем сделать их и их взаимодействие максимально легкими.
Ну один процесс свалился, куда ссылки будут указывать?
При копировании таких проблем нет.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
WH>>Виртуальная машина которая в данном случае неотделима от ОС. S> Кто то совсем недавно по поводу Оберона, с его общей памятью ворчал?
Разницу между разделением изменяемых и не изменяемых данных объяснять или сам поймешь?
S> Копирование со скоростью 6-9 гб/с, дорого но не критично.
А нахрена оно нужно ели можно вообще не копировать?
S> Ну один процесс свалился, куда ссылки будут указывать?
Куда указывали туда и будут.
В чем вообще проблема?
Что думаешь сборщик мусора написать не получится?
S> При копировании таких проблем нет.
За то есть много других.
Например отжер памяти и тормоза.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Roman Odaisky, Вы писали:
RO>Предположим, у нас есть ОС, представляющая собой Java-машину, умеющую исполнять только байткод Java. Вследствие того, что в Java строгая типизация, нет reinterpret_cast и прочих подобных хаков, каждый процесс получает указатели только из одного источника — из оператора new, соответственно, доступ в чужую память невозможен. Это снимает требование аппаратной защиты памяти и вообще звучит привлекательно. Вот только как реализовать IPC? Если у одного процесса есть большой кусок данных, и он хочет предоставить его другому для обработки, то он с помощью какого-нибудь системного вызова передает указатель, чтобы второй процесс смог получить доступ к данным. Однако что, если в том блоке есть указатели куда-то внутрь адресного пространства первого процесса?
Данный вопрос не имеет отношения к верификации, он существует и в обычной ОС и решается стандартным способом. Предположим, что в процессе А имеется файлмэппинг и у процесса Б есть файлмэппинг на тот же файл. Адреса view этих мэппингов в процессах различны (если мы не под Windows95. Для того, чтобы обработка была корректной, надо внутрь этого мэппинга записывать не указатели, а смещения от начала view. Указатели относительны, смещения абсолютны.
Здравствуйте, Mazay, Вы писали:
M>И вообще, если два процесса разделяют общие данные, то это уже не два процесса, а два потока одного процесса.
Поаккуратнее с терминологией, пожалуйста. Так недалеко и до полного абсурда дойти. Разделять-то они разделяют, но каждый их имеет отдельно в своем адресном пространстве
Здравствуйте, mkizub, Вы писали:
M>Нельзя передавать указатели на свою память, это нарушит изоляцию процессов. Указатели на разделяемую память — сколько угодно.
Категорически нет. Адреса разделяемой памяти в разных процессах различны, по крайней мере в Windows линии NT. Вот в 9x можно
The __based keyword allows you to declare pointers based on pointers (pointers that are offsets from existing pointers).
type __based( base ) declarator
One use for pointers based on pointers is for persistent identifiers that contain pointers. A linked list that consists of pointers based on a pointer can be saved to disk, then reloaded to another place in memory, with the pointers remaining valid. For example:
The pointer vpBuffer is assigned the address of memory allocated at some later point in the program. The linked list is relocated relative to the value of vpBuffer.
Note
Persisting identifiers containing pointers can also be accomplished by using memory-mapped files.
Здравствуйте, Pavel Dvorkin, Вы писали:
M>>И вообще, если два процесса разделяют общие данные, то это уже не два процесса, а два потока одного процесса.
PD>Поаккуратнее с терминологией, пожалуйста. Так недалеко и до полного абсурда дойти. Разделять-то они разделяют, но каждый их имеет отдельно в своем адресном пространстве
Я хочу сказать, что если есть надобность так разделять данные, то логично было бы сделать один процесс с двумя потоками. Как раз потому что адресное пространство у процессов разное, по любому придется думать о валидности указателей в обоих процессах: либо использовать смещения, либо хаки вроде __based, либо какой-то аналогичный велосипед.
ЗЫ
Кстати, тут можно маленько пофантазировать. Если процесс это некая сущность объединяющая 1 адресное и N потоков, то вполне можно представить себе некоторую матрицу в которой в столбцах — потоки, в строках — адресные пространства (АП), а в ячейках — аксессоры для синхронизации доступа потоков к АП. Потоки работают с АП через аксессоры и напрямую работают с thread local storages. При должной языковой поддержке может получится вполне удобная и понятная модель для многопоточного программирования на shared-memory системах. Если язык сможет в compiletime и в runtime бить по рукам за попытки сравнивать/присваивать указатели из разных АП как за нарушение типизации, а так же бить за попытку разрезолвить указатель одного АП в другом, то может весьма красиво получиться.
M>Я хочу сказать, что если есть надобность так разделять данные, то логично было бы сделать один процесс с двумя потоками.
Тогда уж один job с двумя процессами
>Как раз потому что адресное пространство у процессов разное, по любому придется думать о валидности указателей в обоих процессах: либо использовать смещения, либо хаки вроде __based
Опять же поосторожней с терминами. Это не хак, а вполне документированная фича.
Здравствуйте, Pavel Dvorkin, Вы писали:
M>>Я хочу сказать, что если есть надобность так разделять данные, то логично было бы сделать один процесс с двумя потоками.
PD>Тогда уж один job с двумя процессами
Ээээээ.... . Вы меня таки уличили в незнании терминов. Как я понимаю процесс == task == N потоков + данные, поток == thread. Что такое job?
Здравствуйте, Mazay, Вы писали:
M>Здравствуйте, Pavel Dvorkin, Вы писали:
M>>>Я хочу сказать, что если есть надобность так разделять данные, то логично было бы сделать один процесс с двумя потоками.
PD>>Тогда уж один job с двумя процессами :-)
M>Ээээээ.... . Вы меня таки уличили в незнании терминов. Как я понимаю процесс == task == N потоков + данные, поток == thread. Что такое job?
Ну для начала task != process, task это единица шедулинга (внутри процесса task есть thread, но могут быть и чисто ядерные задачи без процессов). По крайней мере в наших краях только так.
Ну а по смыслу тут понятно, что job тут — это "самодельное" явление из двух процессов (по контексту — с частично общей памятью).
S>> Ну один процесс свалился, куда ссылки будут указывать? WH>Куда указывали туда и будут. WH>В чем вообще проблема? WH>Что думаешь сборщик мусора написать не получится?
Все возможно, но пока например то, что существует хорошо описал : eao197 http://rsdn.ru/forum/cpp.applied/3147301.1.aspx
S>> При копировании таких проблем нет. WH>За то есть много других. WH>Например отжер памяти и тормоза.
Но есть однозначность данных, которых не будет при падение процесса.
Кстати эо вопрос о внутренних и внешних серверах, если тебе нужен интенсивныйобмен данными, то либо
старайся всю обработку выполнять на сервере, получая лаконичные результаты.
А так я двумя руками за твое предложение, осталось его еще реализовать.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, netch80, Вы писали:
N>Ну для начала task != process, task это единица шедулинга (внутри процесса task есть thread, но могут быть и чисто ядерные задачи без процессов). По крайней мере в наших краях только так.
N>Ну а по смыслу тут понятно, что job тут — это "самодельное" явление из двух процессов (по контексту — с частично общей памятью).
Не знаю, что есть ваши края, но если речь идет о Windows, то все неверно. Нет там task, нет ядерных задач без процессов (любой поток выполняется в каком-то процессе), job не есть самодельное явление, а объект ядра , ну а общая память у двух процессов возможна как в случае, когда они входят в job, так и если не входят.
Здравствуйте, Serginio1, Вы писали:
WH>>Что думаешь сборщик мусора написать не получится? S>Все возможно, но пока например то, что существует хорошо описал : eao197 S>http://rsdn.ru/forum/cpp.applied/3147301.1.aspx
И чего он там описал?
Ерланг? Так ерланг как раз шарит неизменяемые данные между процессами.
Свою библиотеку на С++? Так она вообще к делу не относится.
Если ты про данные которые идут на другую машину то тот уже не IPC, а RPC...
S> Но есть однозначность данных, которых не будет при падение процесса.
Чё?
S>Кстати эо вопрос о внутренних и внешних серверах, если тебе нужен интенсивныйобмен данными, то либо S>старайся всю обработку выполнять на сервере, получая лаконичные результаты.
Какие еще серверы?
Что ты вот с таким сценарием делать будешь? http://rsdn.ru/forum/philosophy/3437966.1.aspx
Здравствуйте, WolfHound, Вы писали:
WH>Ерланг? Так ерланг как раз шарит неизменяемые данные между процессами.
Нт про
Множество мелких процессов и обмен сообщениями -- это средство для обеспечения оказоустойчивости. Падение процесса -- это всего лишь падение одного процесса. Shit happens и с этим нужно считаться. Erlang считается с этим посредством мелких процессов, не имеющих разделяемых данных между собой. Обмен сообщениями -- это необходимая (при этом простая и, одновременно, мощная) форма взаимодействия процессов.
S>> Но есть однозначность данных, которых не будет при падение процесса. WH>Чё?
На что ссылаться будут данные при падении процесса? S>>Кстати эо вопрос о внутренних и внешних серверах, если тебе нужен интенсивныйобмен данными, то либо S>>старайся всю обработку выполнять на сервере, получая лаконичные результаты. WH>Какие еще серверы?
COM,SQL и прочие, то что можно разделить на выполнение в одном процессе и другом так назовем домене. WH>Что ты вот с таким сценарием делать будешь? WH>http://rsdn.ru/forum/philosophy/3437966.1.aspx
Не силен в драйверах, но то что мои скудные познания дают приблизительно это.
SQL хранит данные страницами так же как и ОС, только вот внутри физически странца имеет доп данные.
Наверное нужны драйвера которые вместо данных в странице будут брать из переданных данных.
Если же болб лежит в последовательных страницах то и выдумывать особо нечего.
Кстати здесь уже Mystic прелагал обмен на файлах в памяти
S>> А так я двумя руками за твое предложение, осталось его еще реализовать. WH>Дело техники и некоторого количества бабла.
Мои возможности весьма скромны и ограничены
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
WH>>Ерланг? Так ерланг как раз шарит неизменяемые данные между процессами. S>Нт про S>
S>Множество мелких процессов и обмен сообщениями -- это средство для обеспечения оказоустойчивости. Падение процесса -- это всего лишь падение одного процесса. Shit happens и с этим нужно считаться. Erlang считается с этим посредством мелких процессов, не имеющих разделяемых данных между собой. Обмен сообщениями -- это необходимая (при этом простая и, одновременно, мощная) форма взаимодействия процессов.
Еще раз для особо одаренных: Ерланг шарит данные между процессами. Но так как данные неизменяемые это не создает проблем.
S>>> Но есть однозначность данных, которых не будет при падение процесса. WH>>Чё? S> На что ссылаться будут данные при падении процесса?
Блин. На данные. На что же еще?
S> COM,SQL и прочие, то что можно разделить на выполнение в одном процессе и другом так назовем домене.
Еще раз читай ссылку.
S>Не силен в драйверах, но то что мои скудные познания дают приблизительно это.
Во-во.
S> SQL хранит данные страницами так же как и ОС, только вот внутри физически странца имеет доп данные. S>Наверное нужны драйвера которые вместо данных в странице будут брать из переданных данных.
Ахринеть дайте две.
S> Если же болб лежит в последовательных страницах то и выдумывать особо нечего.
Кроме одной мелочи: Как сказать драйверу сетевухи чтобы он прочитал с винта эти страницы.
Я описал как это сделать так чтобы не появилось лишних зависимостей.
S>Кстати здесь уже Mystic прелагал обмен на файлах в памяти
И причем тут правильные ОС?
S> Мои возможности весьма скромны и ограничены
Надеюсь что ты не думаешь что у всех возможности столь скромны и ограничены?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
N>>Ну для начала task != process, task это единица шедулинга (внутри процесса task есть thread, но могут быть и чисто ядерные задачи без процессов). По крайней мере в наших краях только так. N>>Ну а по смыслу тут понятно, что job тут — это "самодельное" явление из двух процессов (по контексту — с частично общей памятью). PD>Не знаю, что есть ваши края, но если речь идет о Windows, то все неверно.
Нет, о Unix. Контекст Windows нигде ещё в данной теме не фиксировался. А если Вы "не знаете, что есть ваши края", то зачем минус ставите? Просто так?
Тогда сорри.
>А если Вы "не знаете, что есть ваши края", то зачем минус ставите? Просто так?
Убрал. Просто, мне казалось, что из моих сообщений ясно, что я говорю о Windows. Видимо, это не так. Но и тебе стоило просто указать, что речь идет о Unix, вместо того, чтобы ссылаться на туманные края
Здравствуйте, WolfHound, Вы писали: WH>Еще раз для особо одаренных: Ерланг шарит данные между процессами. Но так как данные неизменяемые это не создает проблем.
Если процесс упал, то ссылки на данные могут быть неправильными, т.к. могут содержать данные на закрытые ресурсы.
Т.к. закрытие процесса, гарантирует закрытие ресурсов.
Если это не так, то какой смысл в процессах? Пусть все выпоняется в потоках.
Ну да ладно здесь я сильно некопенгаген.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Если процесс упал, то ссылки на данные могут быть неправильными,
Не могут.
S>т.к. могут содержать данные на закрытые ресурсы.
Каждое слово по отдельности понятно но вот вместе
S>Т.к. закрытие процесса, гарантирует закрытие ресурсов.
Каких еще ресурсов?
Нет никаких ресурсов.
Есть только каналы типа тех что в сингулярити.
Какие проблемы с каналами?
S> Если это не так, то какой смысл в процессах? Пусть все выпоняется в потоках.
Для изоляции.
S> Ну да ладно здесь я сильно некопенгаген.
Это точно.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
S>>Т.к. закрытие процесса, гарантирует закрытие ресурсов. WH>Каких еще ресурсов? WH>Нет никаких ресурсов. WH>Есть только каналы типа тех что в сингулярити. WH>Какие проблемы с каналами?
Т.к. некопенгаген задам вопрос для большего понимания проблемы.
Разговор шел об общей памяти между процессами.
Каналы предлагают Exchange Heap, но это немного другое.
См выделенное.
4.5 Владение
Для гарантии изоляции памяти конечных точек и других данных, передаваемых по каналу, все блоки в Exchange Heap являются ресурсами, которые нужно отслеживать при компиляции. В частности, статические проверки обеспечивают, что доступ к этим ресурсам производится только в точках программы, где она владеет ресурсом, и методами, не нарушающими владение ресурсами. Существует строгая модель владения отслеживаемыми ресурсами. Каждым ресурсом в любой момент времени может владеть не более одного потока (или структуры данных в потоке). Например, если конечная точка передается в сообщении от потока Т1 потоку Т2, ее собственник меняется: от Т1 она переходит к сообщению, а затем, после получения сообщения, к Т2.
Для упрощения статического отслеживания ресурсов указатели на ресурсы могут содержаться только в статических переменных, сообщениях и структурах данных, которые сами отслеживаются. Эти ограничения иногда могут быть обременительными. Поэтому Sing# предоставляет возможность обойти их, сохраняя отслеживаемые ресурсы косвенно, внутри структур данных, через абстракцию TRef.
4.6 TRef
TRef – это ячейка хранения типа TRef<T>, содержащая отслеживаемую структуру данных типа Т. Сигнатура TRef такова:
class TRef<T> where T: ITracked
{
public TRef([Claims] T i_obj);
public T Acquire();
public void Release([Claims] T newObj);
}
При создании TRef<T> конструктор требует в качестве аргумента объект типа Т. Вызывающая сторона должна владеть объектом на стороне создания. После создания владение передается созданному TRef. Для получения содержимого TRef используется метод Acquire. Если TRef заполнен, он возвращает свое содержимое и передает владение стороне, вызвавшей Acquire. После этого TRef считается пустым. Release передает владение объектом T от вызывающей стороны TRef-у. После этого TRef является заполненным. TRef-ы потокобезопасны. Операция Acquire блокируется, пока TRef заполнен.
TRef – это компромисс между статическими и динамическими проверками. При использовании TRef множественные некорректные запросы превращаются во взаимоблокировки, и освобождением ресурса занимается механизм финализации сборщика мусора.
4.7 Exchange Heap
Поскольку владение блоками памяти передается при обмене сообщениями от одного потока или процесса другому, Singularity необходим способ выделения и отслеживания таких блоков. Система каналов требует, чтобы параметры сообщения были или скалярами, или блоками в Exchange Heap. Есть два вида блоков Exchange Heap: индивидуальные блоки и векторы. Их типы записываются, соответственно, так:
using Microsoft.Singularity.Channels;
R* in ExHeap pr;
R[] in ExHeap pv;
ПРИМЕЧАНИЕ
Конечные точки в Exchange heap представлены как отдельные блоки.
Тип указателя pr говорит, что он указывает на структуру R в Exchange Heap. ExHeap – это тип, определенный исполняющей системой, обеспечивающей выделение, освобождение и другую поддержку данной кучи. Тип pv – это вектор R в Exchange Heap.
Инвариант Exchange Heap в том, что она не содержит никаких указателей на GC-кучу какого либо процесса. Таким образом, тип R должен быть обмениваемым типом, то есть примитивным value-типом (int, char и т.д.), перечислением или простой структурой с полями обмениваемых типов.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Т.к. некопенгаген задам вопрос для большего понимания проблемы. S> Разговор шел об общей памяти между процессами. S>Каналы предлагают Exchange Heap, но это немного другое.
Если ты не понимаешь что сингулярити лишь одна из возможных реализаций и что в другой реализации каналы могут иметь иные ограничения то я тебе ничем не могу помочь.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Serginio1, Вы писали:
S>>Т.к. некопенгаген задам вопрос для большего понимания проблемы. S>> Разговор шел об общей памяти между процессами. S>>Каналы предлагают Exchange Heap, но это немного другое. WH>Если ты не понимаешь что сингулярити лишь одна из возможных реализаций и что в другой реализации каналы могут иметь иные ограничения то я тебе ничем не могу помочь.
Зачем тогда ссылался на сингулярити. Мне честно интересен сам механизм, иначе бы и не впрягался в этоту беседу.
Что касается объектов не содержащих ресурсов и имутабельных, вполне возможно держать их в единой куче, а что содержит ресурсы и изменяемые,то типа TRef, или
сериализация ремотинг.
При выгрузке процесса, нужно будет подчистить за собой освободив ресурсы.
Сейчас по аналогии с доменом, ресурсы закрываются, память высвобождается. Все просто.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Зачем тогда ссылался на сингулярити.
За тем что каналы из сингулярити отличный примитив для общения между процессами.
S> Мне честно интересен сам механизм, иначе бы и не впрягался в этоту беседу.
Механизм чего? Того как сборщик мусора на неизменяемой кучи работает? Так это долго рассказывать.
Или общения между процессами? Тут все очень просто. Повторю еще раз: Просто передаем ссылку на неизменяемый объект в другой процесс и все. Дальше разберется сборщик мусора.
S>Что касается объектов не содержащих ресурсов и имутабельных, вполне возможно держать их в единой куче, а что содержит ресурсы и изменяемые,то типа TRef, или сериализация ремотинг.
Тут вообще каша. Ничего не понял.
С тобой очень трудно разговаривать.
Выражайся яснее.
S>При выгрузке процесса, нужно будет подчистить за собой освободив ресурсы.
Какие еще ресурсы?
Выражайся яснее.
S>Сейчас по аналогии с доменом, ресурсы закрываются, память высвобождается. Все просто.
И тут все просто. Каналы закрываются. Кучи связанные с процессом тоже просто освобождаются.
А с разделяемыми данными разберутся потом.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
S>>Что касается объектов не содержащих ресурсов и имутабельных, вполне возможно держать их в единой куче, а что содержит ресурсы и изменяемые,то типа TRef, или сериализация ремотинг. WH>Тут вообще каша. Ничего не понял. WH>С тобой очень трудно разговаривать. WH>Выражайся яснее.
Для имутабельных про S>>При выгрузке процесса, нужно будет подчистить за собой освободив ресурсы. WH>Какие еще ресурсы? WH>Выражайся яснее.
Ресурсы это Файлы, каналы, итд. что при выгрузки процесса должно закрыться, а значит не должно иметь прямых ссылок из других процессов.
А также мутабельные объекты должны храниться в куче процесса.
S>>Сейчас по аналогии с доменом, ресурсы закрываются, память высвобождается. Все просто. WH>И тут все просто. Каналы закрываются. Кучи связанные с процессом тоже просто освобождаются. WH>А с разделяемыми данными разберутся потом.
Только кучи должны быть разными для разделяемых и неразделяемых объетов.
Ладно приблизительно понял, Спасибо.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, mkizub, Вы писали:
PD>>Категорически нет. Адреса разделяемой памяти в разных процессах различны, по крайней мере в Windows линии NT. Вот в 9x можно
M>Речь же идёт о некоей гипотетической ОС, которая сама вся из себя верифицируемая. Как эту ОС напишешь — так и будет.
А, ну тогда да. Остается дождаться появления ее на свет божий и тотального вытеснения ею Windows
