Здравствуйте, Roman Odaisky, Вы писали:
RO>Тогда zero copy не выйдет.
За надежность нужно платить.

Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, Serginio1, Вы писали:

S>>Посмотри http://rsdn.ru/article/singularity/singularity.xml

Автор(ы): Galen Hunt, James Larus, Martin Abadi, Mark Aiken, Paul Barham, Manuel Fahndrich, Chris Hawblitzel, Orion Hodson, Steven Levi, Nick Murphy, Bjarne Steensgaard, David Tarditi, Ted Wobber, Brian Zill
Дата: 02.03.2006
Singularity – исследовательский проект Microsoft Research, который начался с вопроса: на что была бы похожа программная платформа, если спроектировать ее на пустом месте, и во главу угла поставить не производительность, а надежность?

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])) внутри любого процесса.

Хочешь — копируй целиком. Хочешь — передавай по частям. А хочешь — можешь поделить между процессами.

Здравствуйте, 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)

Нот а ток!

S>>

S>>Главное решение в дизайне – инвариант независимости памяти: указатели между объектными пространствами указывают только на Exchange Heap. В частности, ядро не имеет указателей на объектное пространство процесса, и ни один процесс не имеет указателя на объекты другого процесса. Это гарантирует, что каждый процесс может подвергнуться сборке мусора и быть выгруженным без взаимодействия с другими процессами.

RO>Тогда zero copy не выйдет.

можно получить сколь угодно близкое приближение к нему даже при необходимости копирования между процессами.

Называется "ленивый порядок вычислений".

Serginio1 wrote:

> Главное решение в дизайне – инвариант независимости памяти:
> указатели между объектными пространствами указывают только на
> Exchange Heap. В частности, ядро не имеет указателей на объектное
> пространство процесса, и ни один процесс не имеет указателя на
> объекты другого процесса. Это гарантирует, что каждый процесс может
> подвергнуться сборке мусора и быть выгруженным без взаимодействия с
> другими процессами.
Было бы интересно рассмотреть возможность переноса объектов из одного пространства в другое без копирования, а просто поменяв некий дескриптор у объекта, что позволит сохранить инвариант.

Здравствуйте, ., Вы писали:

.>Было бы интересно рассмотреть возможность переноса объектов из одного пространства в другое без копирования

Может быть, с помощью чего-то вроде uniqueness typing system из Clean?

Здравствуйте, Roman Odaisky, Вы писали:

RO>Предположим, у нас есть ОС, представляющая собой Java-машину, умеющую исполнять только байткод Java. Вследствие того, что в Java строгая типизация, нет reinterpret_cast и прочих подобных хаков, каждый процесс получает указатели только из одного источника — из оператора new, соответственно, доступ в чужую память невозможен. Это снимает требование аппаратной защиты памяти и вообще звучит привлекательно. Вот только как реализовать IPC? Если у одного процесса есть большой кусок данных, и он хочет предоставить его другому для обработки, то он с помощью какого-нибудь системного вызова передает указатель, чтобы второй процесс смог получить доступ к данным. Однако что, если в том блоке есть указатели куда-то внутрь адресного пространства первого процесса? При отсутствии аппаратной защиты памяти второй процесс, нарушая принцип минимальных привилегий, сможет влезть куда не просят.

Посмотри на http://msdn.microsoft.com/ru-ru/library/system.appdomain.aspx это как-бы приложение в как-бы OS.

Здравствуйте, Roman Odaisky, Вы писали:

RO>Много думал, но не понял, как в ОС, исполняющих только верифицированный код, можно реализовать IPC, соблюдая изоляцию процессов.
Да как нефиг делать.

RO>Предположим, у нас есть ОС, представляющая собой Java-машину, умеющую исполнять только байткод Java.
На основе ВМ уровня жабы могут быть только экспериментальные поделки.
Ибо система типов жабы настолько убога что ей проверить почти ничего нельзя.
Нужна система типов уровня agda. Вот на ней уже можно сделать что-то практичное.

RO>Вот только как реализовать IPC? Если у одного процесса есть большой кусок данных, и он хочет предоставить его другому для обработки, то он с помощью какого-нибудь системного вызова передает указатель, чтобы второй процесс смог получить доступ к данным. Однако что, если в том блоке есть указатели куда-то внутрь адресного пространства первого процесса? При отсутствии аппаратной защиты памяти второй процесс, нарушая принцип минимальных привилегий, сможет влезть куда не просят.
Тут два варианта.
1)Неизменяемые типы данных.
Можно передавать между процессами сколько угодно и ни кто ни куда не влезет.

2)uniqueness типы. Это такие типы на объекты которых может быть только одна ссылка.
А раз есть только одна ссылка то тоже никто и ничего не сделает.

RO>В традиционных системах эта задача решается тривиально, даже без копирования данных между процессами (разделяемая память, splice(2)/vmsplice(2) и т. д.).
Тривиально аж дальше некуда

RO>И еще, если на каждый байт памяти могут быть указатели из скольки угодно процессов,
На каждый не может.
Это тебе не С++ где можно на середину объекта ссылаться.

RO>как это скажется на GC?
Никак.
Особенно если учесть что GC для неизменяемой кучи гораздо проще и может срезать кучу углов вплоть до сведения ГЦ паузы к вызову барьера памяти.
А если еще учесть что region inference тоже никто не отменял...

Здравствуйте, ., Вы писали:

.>Было бы интересно рассмотреть возможность переноса объектов из одного пространства в другое без копирования, а просто поменяв некий дескриптор у объекта, что позволит сохранить инвариант.
Кто будет следить за временем жизни. Да и насколько эти сложности перенесут больше бенефита перед копирования или ремотинга?
Меж процесное взаимодействие не краеугольный камень.

Здравствуйте, Serginio1, Вы писали:

.>>Было бы интересно рассмотреть возможность переноса объектов из одного пространства в другое без копирования, а просто поменяв некий дескриптор у объекта, что позволит сохранить инвариант.
S> Кто будет следить за временем жизни.
Виртуальная машина которая в данном случае неотделима от ОС.

S>Да и насколько эти сложности перенесут больше бенефита перед копирования или ремотинга?
Большие.
Ты что думаешь копирование бесплатно?

S> Меж процесное взаимодействие не краеугольный камень.
Он самый.
Ибо если делать по уму то нужно ликвидировать потоки и оставить только процессы.
Причем сделать их и их взаимодействие максимально легкими.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:

.>>>Было бы интересно рассмотреть возможность переноса объектов из одного пространства в другое без копирования, а просто поменяв некий дескриптор у объекта, что позволит сохранить инвариант.
S>> Кто будет следить за временем жизни.
WH>Виртуальная машина которая в данном случае неотделима от ОС.
Кто то совсем недавно по поводу Оберона, с его общей памятью ворчал?
S>>Да и насколько эти сложности перенесут больше бенефита перед копирования или ремотинга?
WH>Большие.
WH>Ты что думаешь копирование бесплатно?
Копирование со скоростью 6-9 гб/с, дорого но не критично.
S>> Меж процесное взаимодействие не краеугольный камень.
WH>Он самый.
WH>Ибо если делать по уму то нужно ликвидировать потоки и оставить только процессы.
WH>Причем сделать их и их взаимодействие максимально легкими.
Ну один процесс свалился, куда ссылки будут указывать?
При копировании таких проблем нет.

Здравствуйте, Roman Odaisky, Вы писали:

Почитай о Сингулярити (статья есть на нашем сайте). Там эта проблема решена.

Здравствуйте, Serginio1, Вы писали:

WH>>Виртуальная машина которая в данном случае неотделима от ОС.
S> Кто то совсем недавно по поводу Оберона, с его общей памятью ворчал?
Разницу между разделением изменяемых и не изменяемых данных объяснять или сам поймешь?

S> Копирование со скоростью 6-9 гб/с, дорого но не критично.
А нахрена оно нужно ели можно вообще не копировать?

S> Ну один процесс свалился, куда ссылки будут указывать?
Куда указывали туда и будут.
В чем вообще проблема?
Что думаешь сборщик мусора написать не получится?

S> При копировании таких проблем нет.
За то есть много других.
Например отжер памяти и тормоза.

Здравствуйте, VladD2, Вы писали:

VD>Почитай о Сингулярити (статья есть на нашем сайте). Там эта проблема решена.

Да не решена она там. Приходится копировать данные на особую кучу и ограничивать себя примитивными типами.

Здравствуйте, Roman Odaisky, Вы писали:

RO>Да не решена она там. Приходится копировать данные на особую кучу и ограничивать себя примитивными типами.

Почему примитивными? Что мешает создавать типы любой сложности в особой кучи?

Собственно тоже самое и в современных ОС с аппаратной защитой. Только вместо травмобезопасной общей кучи мы имеем тупо разделяемую память.

Хочется передать, что-то более сложное — сериализуй состояние и запихни его в сообщение.

Здравствуйте, Roman Odaisky, Вы писали:

RO>Много думал, но не понял, как в ОС, исполняющих только верифицированный код, можно реализовать IPC, соблюдая изоляцию процессов.

Дело не столько в верифицированном коде, сколько в том, что у процесса должно быть свое адресное пространство. В неверифицируемом коде нормального способа расшарить данные тоже не существует. То что есть возможность отдать кусок данных из своего адресного пространства через splice(2)/vmsplice(2) не сильно спасает, так как если у тебя есть граф раскинувшийся по всему адресному пространству если передавать его через splice(2)/vmsplice(2), то указатели все равно окажутся невалидными. Если же с самого начала работать в расшаренном куске данных, использую вместо указателей смещения в пределах этого куска, то это ничем не будет отличаться от уже названного memory-mapped файла.

И вообще, если два процесса разделяют общие данные, то это уже не два процесса, а два потока одного процесса.

Здравствуйте, Roman Odaisky, Вы писали:

RO>Предположим, у нас есть ОС, представляющая собой Java-машину, умеющую исполнять только байткод Java. Вследствие того, что в Java строгая типизация, нет reinterpret_cast и прочих подобных хаков, каждый процесс получает указатели только из одного источника — из оператора new, соответственно, доступ в чужую память невозможен. Это снимает требование аппаратной защиты памяти и вообще звучит привлекательно. Вот только как реализовать IPC? Если у одного процесса есть большой кусок данных, и он хочет предоставить его другому для обработки, то он с помощью какого-нибудь системного вызова передает указатель, чтобы второй процесс смог получить доступ к данным. Однако что, если в том блоке есть указатели куда-то внутрь адресного пространства первого процесса?

Данный вопрос не имеет отношения к верификации, он существует и в обычной ОС и решается стандартным способом. Предположим, что в процессе А имеется файлмэппинг и у процесса Б есть файлмэппинг на тот же файл. Адреса view этих мэппингов в процессах различны (если мы не под Windows95. Для того, чтобы обработка была корректной, надо внутрь этого мэппинга записывать не указатели, а смещения от начала view. Указатели относительны, смещения абсолютны.

Здравствуйте, Mazay, Вы писали:

M>И вообще, если два процесса разделяют общие данные, то это уже не два процесса, а два потока одного процесса.

Поаккуратнее с терминологией, пожалуйста. Так недалеко и до полного абсурда дойти. Разделять-то они разделяют, но каждый их имеет отдельно в своем адресном пространстве

Здравствуйте, mkizub, Вы писали:

M>Нельзя передавать указатели на свою память, это нарушит изоляцию процессов. Указатели на разделяемую память — сколько угодно.

Категорически нет. Адреса разделяемой памяти в разных процессах различны, по крайней мере в Windows линии NT. Вот в 9x можно

Кстати, в VC++ есть вот такое

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:

// based_pointers1.cpp
// compile with: /c
void *vpBuffer;
struct llist_t {
void __based( vpBuffer ) *vpData;
struct llist_t __based( vpBuffer ) *llNext;
};


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.