И снова Лёня на связи! Systemd и безопасность!

вот в ChrysaLisp кстати, правильно сделали акторную многозадачность Parallel OS

ChrysaLisp uses a virtual CPU instruction set to eliminate the use of x64, ARM64, RISCV64, or VP64 native instructions. Currently, it compiles directly to native code, but it has the capability to also be translated to byte code form and use runtime translation.

To avoid the need for register juggling for parameter passing, all functions define their register interface, and parameter sources and destinations are automatically mapped using a topological sort. If non-DAG mappings are detected, the user can address them with a temporary. The software also includes operators to make it easy to bind parameters to dynamic bound functions, relative addresses, auto-defined string pools, references, and local stack frame values. Output parameters that are not used can be ignored with an underscore.

ChrysaLisp has a powerful object and class system that is not limited to just the assembler but is quite as capable as a high level language. It allows for the definition of static classes or virtual classes with inline, virtual, final, static, and override methods. The GUI and Lisp are built using this class system.

It has function-level dynamic binding and loading. Functions are loaded and bound on demand as tasks are created and distributed. Currently, functions are loaded from the CPU file system where the task is located, but in the future, they will come from the server object that the task was created with and will be transported across the network as needed. Functions are shared among all tasks that use the same server object, so only one copy of a function is loaded, regardless of how many tasks use it.

The system functions are accessed through a set of static classes, which makes it easy to use and eliminates the need to remember static function locations, and also decouples the source from changes at the system level. The interface definitions for these functions can be found in the sys/xxx.inc files.

A command terminal with a familiar interface for pipe style command line applications is provided with args vector, stdin, stdout, stderr etc. Classes for easy construction of pipe masters and slaves, with arbitrary nesting of command line pipes. While this isn't the best way to create parallel applications it is very useful for the composition of tools and hides all the message passing behind a familiar streams based API.

Там еще 11 публичных функций, которые экспортирует libsystemd. Их тоже все самому писать?

Микроядро L4 как основа ядра ОС

6. API

API L4 содержит очень небольшое количество функций. В оригинальной версии ядра их было всего 7. Для API версии X.2 (L4Ka::Pistachio) имеется 11 системных вызовов.

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

а системда что-то на микроядро совсем не тянет

монолит, однако

вот например, многопоточный терминал: ChrysaLisp/blob/master/apps/tui/ install.lisp сервер tui.lisp tui_child.lisp

здесь видим task-mailbox и mail-read,mail-send, task-sleep которые работают с такими акторноподобными микрозадачами

GUI (например, здесь raymarch/app.lisp реализован похожим образом, то есть, он уже по построению получается многопоточный через мейлбоксы

причём всё это можно ещё и раскидать на virtual processor сети динамически организуемой топологии

то есть делать что-то типа GRID, ну или децентрализованной акторной модели объектов

в Elate/TaoOS откуда ChrysaLisp ранее был tool который более компактно реализовал похожую акторную многозадачность

в общем, как-то так нужно делать.

класс Pipe pipe.inc например, реализован через мейлбоксы и open-pipe

в общем, объекты получаются скорее акторы

лисп, кстати, возможно нужен немного другой.

ближе к vau-expressions kernel scheme by John Schutt.

vau-expressions от lambda expressions отличается тем, что макросы реализованы аналогично FEXPR и например, apply[f;args], eval[e;a], evcon[e;a], evlis[n;a] и прочее выглядят как каррированное для некоторого lisp-3:

apply[f;args;l], eval[e;a;l], evcon[e;a;l], evlis[n;a;l]

где l-это некоторый locus:namespace – окружение, в котором все эти формы вычисляются (и которое в vau-expressions передаётся явно)

в общем, этим можно более выразительно сделать «создать символ в конкретном окружении», «обмениваться символами через неймбоксы» – реализовать объекты/акторы/персистентные объекты, модули, пространства имён и т.п.

опять же, схему лучше бы сделать с гигиеничными макрами а не коммонлисповым defmacro и gensym.

в общем, я бы на ChrysaLisp сделал сначала нечто вроде простенькой ribbit схемы которую бы уже делал акторную с несколькими пространствами имён в которых акторы обмениваются сообщениями через мейлбоксы или напрямую через пространства имён в духе plan 9 fs namespaces и вызовом типа bind before/after.

В libsystemd предоставляется доступ к 12 базовым API

ну просто образец модульности, лолЪ

• L4Ka::Pistaschio – 11 сисколлов реализующих IPC, а не разномастных апей

• ChrysaLisp – акторная многозадачность на уровне task mailbox или более компактная, на уровне функций

• ponylang – share nothing акторная модель на основе reference capabilities

• ActiveOberon и AOS – обероны пассивные активные – каждый модуль может стать актором с синхронизацией на основе семафоров и мониторов

• Project Oberon – обероны пассивные однозадачные модульные: модули Kernel, System которые UNSAFE, затем GC, StdLoader, linker, остальные вроде StdInterpreter

• Ada tasks/entry – синхронизация тредов (скорее, корутин) встроенных в язык на основе рандеву между task entry и попыток делать synchronized методы типа Явы к limited controlled памяти и типам данных

• Inferno/Limbo/Dis – каналы Хоара, горутины, ADT модули, Gc, типизированные ссылки, регистровая VM (а не стековая)

• Go/native runtime – -"- практически Limbo только self-hosted и без VM Dis

• Plan9, Rio, 8.5, Styx/P9FS, vfork/rfork, notify типа мейлбоксов вместо сигналов – на родной няшной сишечке

• ос на Modula-2, Ada, Oberon-2

• ос на лиспе, акторной модели

• смоллток, селф, NetLogo, Io – акторная модель

везде здесь более модульное API — и практически везде более модульное, более гранулярной модульности чем в SystemD.

в SystemD же полный фейспалм. монолитный копрокод, сильносвязанный, небось ещё и с циклическими ссылками между.

dbus зачем-то ему нужен обязательно – ну вот зачем?

ну и прочее.

леня потный конечно же, лучше всех знает как надо.

архитектор же.

модульность – это сложно, ога.

Qt6 QPA, plugins

22 directories, 83 files

XXX objects, YYY methods, ZZZ namespaces, NNN templates, YYY moc objects

С++ ну тоже просто этакий образец модульности :)))

Qt6 C++ – это очень просто, лол :))

но есть – где? Limbo/Inferno, Go/тот же лимбо, ActiveOberon/AOS, ponylang, L4/C++, Ada/tasks, акторное чё-нить, ну и т.п.

Да, да, да, пытаюстся, но очень неуверенно.

при этом оно таки на С++, но не суть. С++ там примерно для абстрактной фабрики через миксины, больше шаблонов богу шаблонов. эта абстрактная фабрика выдаёт токены типа ролевого мандатного доступа на capabilities, то есть, корректно типизированные ссылки на объекты ядра (микроядра). поверх которых затем делаем быстрый синхронный IPC...
кстати, а почему именно асинхронных? вот в L4 они синхронные и быстродействие IPC повысилось в 20…100 раз

Синхронное программирование — путь вникуда, поскольку все прикладные задачи требуют времени на выполнение, не решив проблему работы с растянутой во времени операцией ты никуда не продвинешься. Классический пример — работа с сетью.

И не в последнюю очередь проблемы создает архитектура процессоров, которая построена оптимизирована под Си (а не наоборот),

какого именно? тот же Chris Lattner из LLVM сетует что дескать, много всяческого UB из-за которого конпелятор сишки должен быть достаточно умным чтобы что-то там догадываться распараллеливать.

Классический пример — volatile память и strict aliasing. Эта область несколько раз насыщалася UB по причине того, что оригинальный Си сам по себе — неэффективный, не поддающийся оптимизациям язык.

опять же – имеются в виду что-то вроде map/grant/revoke или sendrecv из L4?

Я не настолько глубоко разбирался в L4 — может быть это оно и есть.

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

да ладно. вот L4 например вполне взлетело, и опять же – по быстродействию IPC там быстрее на порядки.

Куда взлетело? За пределы proof of concept оно не вышло.

в общем, вопрос можно переформулировать так: какая модель многозадачности и IPC была бы более адекватна и насколько она тут должна быть завязана на сам язык???

Проблема не в ОС, а в процессоре. Сами процессоры для межядерного взаимодействия активно используют event-driven и неразделяемые состояния, но на уровне ОС по прежнему применяется подход плоской общей памяти, который для многопоточной/многозадачной обработки просто несостоятелен. Хотя бы потому, что цена когерентности кэша примерно пропорциональна числу процессоров.

Сколько бы я не пытался придумать безопасные надежные механизмы вычислений на базе lock-free алгоритмов ­— у меня это не получалось сделать. Может быть кто-то через сто лет и найдет работающий подход, но я всё больше склоняюсь к тому, что это просто невозможно сделать, беспорядочная модификация общей памяти несколькими алгоритмами имеет экспоненциальную сложность оценки (по отношению к числу шагов, грубо говоря, строк кода), потому для общего случая нерешаема за адекватное время. Прежде всего проблему не нужно создавать, и тогда ее не придется решать. Синхронность и однозадачность — это тоже не решение, поскольку не масштабируется.

нужно что-то типа π-исчисления и сетей Петри.

Возможно, но я не уверен.

вот недавно перечитывал recursive.pdf Recursive Functions of Symbolic Expressions and Their Comutation by Machine Джона Маккарти про формализацию лиспа, навеяло этим:
...
особо доставляют аналогии внешнего и внутреннего с двухэтажной W-грамматикой синтаксиса и семантики метаправил и гиперправил алголовых.

Не понимаю, каким боком всё это к нашей дискусии.