OberonCore

Да как угодно управлять можно... уже под частную задачу.

Можно иметь базовую библиотеку, которая позволяет создать и потом открыть по имени такой буфер в разных рантаймах, получив к нему интерфейс типа Files.File. Так становится удобно и прокачивать сообщения структурированные, как хранимые объекта типа Stores.Store.

Ну, там еще вопрос в синхронизации и в сигнализировании, что вот новый шмат готов и можно читать. Но это действительно уже детали.

Единственный минус который я вижу во множестве рантаймов в одном процессе - потоки становятся столь же тяжеловесными как и процессы, то есть оверхед по памяти. Но это в общем то, минусом является весьма условным, ибо много потоков/рантаймов создавать не требуется.

Для ББ вопрос запуска ещё одного рантайма ~ 2МБ.
Ну плюс дублирование своего кода, каких-то своих данных и прочего хозяйства...
Всё равно мелочи )

Разве 2МБ? не меньше?

Возможно, и меньше... Я не о голом Kernel говорю, а о некоторой стандартной группе модулей... В любом случае, даже для 32-ядерного сервера вопрос мелочный ))

Ну, я же говорю - стоимость такого потока+рантайм примерно равен запуску еще одного процесса в системе. Другое дело, что общение между этими потокорантаймами происходить будет с меньшими накладными расходами нежели общение между процессами. Описанную мною задачу это вполне решает.

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

Вот так https://bitbucket.org/petryxa/mbp