[post UNIX?] [когда будет?] Универсальный интерфейс-конструктор

find /var /dev -type s , и не задавай больше глупых вопросов.

Мог бы просто сказать, что я пытаюсь добиться решения совсем другой задачи.

И да, квотирование предотвращает множество непоняток.

> на то они и стандартные. Никто не мешает открывать больше
И как их открывать, не создавая предварительно лишних fifo-файлов?

на то они и стандартные. Никто не мешает открывать больше

2> есть, а где 2| или что-то подобное? Как оно пишется?

>Как раз наоборот. Если софт работает в годной ВМ, то можно делать очень гибкие политики безопасности. А еще не тратится время на переключение контекста.
Никакой разницы не будет, проверку по политике безопасности придется проводить при каждом обращении к памяти, это затраты на уровне переключения контекста. Причем меморилики в данном случае не починишь простым убиванием процесса.

Если ты про одно адресное пространство, то проблем быть не должно: памятью должна управлять ВМ.

Проблема в данном случае не в том, чтобы разделить саму память, а в том, чтобы еще и именна переменных были известны, которые на эту память указывают, они ведь нигде не хранятся. А это уже нетривиальная задача, тем более может быть запущенно более 1 экземпляра программы.

>> То есть он имеет в виду, что никак не получится без использования именованных пайпов перенаправить 1 поток в одну программу, а 2 в другую.

А что, за использование именованных пайпов по рукам бьют?

Это костыли, потому что при их использовании, приходится их предварительно создавать. Впрочем, можно было бы сделать виртуальную файловую систему типа /dev/fifo/ при попытке записи в которую автоматом создавался пайп

> Plan9 и Libmo - всё уже сделано.
Ну я знаю, что это пост-юникс, но там вроде был упор на сетевую прозрачность, а не на множество потоков.

> Никакой разницы не будет, проверку по политике безопасности придется проводить при каждом обращении к памяти, это затраты на уровне переключения контекста.
Да там вообще много каких затрат будет. За все приходится платить. ;)
И, кстати, проверки будут точно не при *каждом* обращении к памяти.
Пример:
1) Приложению нужно получить доступ к полю объекта.
2) Оно делает запрос ВМ.
3) ВМ решает, разрешить ли доступ к участку памяти, занимаемому полем. (проверка одна)
4) Если да, то возвращает ссылку на поле.

Проблема в данном случае не в том, чтобы разделить саму память, а в том, чтобы еще и именна переменных были известны, которые на эту память указывают, они ведь нигде не хранятся. ...

Ну, это уже детали. К тому же, еще и не правда. В Лиспе хранятся, например, имена символов.

>Мог бы просто сказать, что я пытаюсь добиться решения совсем другой задачи.

я отвечал топикстартеру. Потом отвечал ярегу с его альтернативным видением задачи. Потом пришел ты и начал жестко тупить :)

>> на то они и стандартные. Никто не мешает открывать больше

И как их открывать, не создавая предварительно лишних fifo-файлов?

man 2 pipe :)

А вообще, реальную задачу в студию.

>1) Приложению нужно получить доступ к полю объекта.

2) Оно делает запрос ВМ.

3) ВМ решает, разрешить ли доступ к участку памяти, занимаемому полем. >(проверка одна)

4) Если да, то возвращает ссылку на поле.

Но приложение может ведь и нелегальным путем получить ссылку на поле, как это регулировать? Сейчас ведь одна из популярнейших атак - «переполнение буфера» используется для того, чтобы получить доступ к памяти в которой расположены функции, а тут оно на тарелочке будет?

Ну, это уже детали. К тому же, еще и не правда. В Лиспе хранятся, например, имена символов.

Есть 10 экземпляров nginx, как различать различные имена переменных? Что делать, когда второй экземпляр nginx упадет и запустится 11-ый?

Или ты что-то не то имел ввиду?

Именно. что-то вроде

stdout   __ prog2 | prog4 _
        /                  \___stdin_
prog1                       __stdctrl_\ prog6
        \__ prog3 | prog5 _/
stderr

То есть stdout от программы 1 перенаправляется на один конвейер, stderr на другой, они обрабатываются, а потом обработанный stderr управляет командой prog6, а обработанный вывод команды 1 подаётся на её вход.

> Сейчас ведь одна из популярнейших атак - «переполнение буфера» используется для того, чтобы получить доступ к памяти в которой расположены функции, а тут оно на тарелочке будет?
Напротив, в теории переполнение буфера будет невозможно т.к. выделением памяти управляет ВМ.

Но приложение может ведь и нелегальным путем получить ссылку на поле, как это регулировать?

Из-за критической уязвимости - да...

Есть 10 экземпляров nginx, как различать различные имена переменных? Что делать, когда второй экземпляр nginx упадет и запустится 11-ый?

Не уверен, что понял вопрос... Но он в любом случае преждевременный. И не думаю, что встанет проблема «как же разделять имена переменных» =)

Кастую интересную ссылку: http://en.wikipedia.org/wiki/Language-based_system

> А какие ещё ты можешь придумать _стандартные_(т.е. присущие всем программам) потоки?
Например stdctrl, стандартный поток управления.
Сейчас в программах обычно вместо него stdin используют, а если нужно что-то обрабатывать, то внешний файл со скриптами или параметр командной строки.

А вот как по-твоему сделать что бы sed управлялся одним конвейером, формирующим что-нибудь вроде «s/foo/bar», а ввод данных получал от другого?

>Из-за критической уязвимости - да...
Ну допустим злоумышленник берет маленькую программу, которая просто зануляет всю память. Ей ведь не нужны ссылки, чтобы занулить всю память.

Не уверен, что понял вопрос... Но он в любом случае преждевременный. И не думаю, что встанет проблема «как же разделять имена переменных»

Почему? Данные можно в общую память класть уже 100 лет в обед, man shmem. Только вот как определить что это за память, где она, какого типа объект там находится и как вообще к нему обращаться - весьма не тривиально.

Хотя в случае с sed можно юзать ``, но что если взять вместо медиаплеер, и одна из программ например cat /dev/keyboard | sed 's/ /pause/', упавляет им, а другая — например curl http://site.org/mediafile.ogg даёт входной поток?

> Ну допустим злоумышленник берет маленькую программу, которая просто зануляет всю память. Ей ведь не нужны ссылки, чтобы занулить всю память.
Мне кажется, ты таки не понимаешь, что такое автоматическое управление памятью. ;)
Программы в принципе не могут работать с памятью напрямую. Этим занимается компилятор при компиляции и ВМ в рантайме.

Только вот как определить что это за память, где она, какого типа объект там находится и как вообще к нему обращаться - весьма не тривиально.

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

>Программы в принципе не могут работать с памятью напрямую. Этим занимается компилятор при компиляции и ВМ в рантайме.
Я не понимаю. VM возвращает ссылку на поле. Что мешает манипулировать этой ссылкой? Вы же сами говорите, что проверка не будет вызываться каждый раз.

А указатели на объекты никто не отменял!

А описание типа объекта из хаскеля в лисп передавать электронной почтой будете?

> Что мешает манипулировать этой ссылкой?
Да ничего не мешает, наверное. Ссылка - она и есть ссылка.

Вы же сами говорите, что проверка не будет вызываться каждый раз.

Не совсем так: «проверки будут точно не при *каждом* обращении к памяти». Не в ущерб безопасности, конечно.

А описание типа объекта из хаскеля в лисп передавать электронной почтой будете?

Ну, это просто будут разные типы, например... Аналогия: JVM и ее друзья-ЯП.

>стандартный поток управления

Трудно представить, для чего, скажем, sed-у отвязанный от stdin-а поток управления. Программа будет генерировать разный результат в зависимости от уровня паралельности системы. Т.ч. IMО идея хороша только на первый взгляд.

> для чего, скажем, sed-у отвязанный от stdin-а поток управления.

Ну sed-у может быть и не нужно, а вот например mplayer-у вполне нужно, и там даже есть возможность его юзать. Но это не стандартный поток, а задаваемый в конфиге файл.