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

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

точно через копирование? мне всегда казалось, что там симофор на  батчи чтения/записи просто

хипстеры изобрели ffi

shm не участвует в основном. Представь как например стриминговый подход например через tcp

так на локальной петле tcp по сути даунгрейдится до шаред мемори, если я ничего не путаю

не обязательно ffi

у тебя read определен как копирующий вызов

?

конечно это зависит от определение FFI, но как я отметил там может быть прослойка

обрати внимание на сигнатуру

ос в конечном счете тоже будет юзать шаред памяти для связи между процессами но сам интерфейс  тех подходов что в списке (Unix Domain Sockets, TCP on localhost, UDP on localhost, sdtin/stdout) предполагает что мы пересылаем какой-то кусок данных а это именно что копирование, более того это еще и системный вызов и переключение контекста на каждую пересылку, когда же шаред-память вообще работает без системных вызовов (полностью в юзерспейсе)

А для чего делаешь, если не секрет? У нас есть реализация ffi при не шаред памяти на нескольких языках

без системных вызовов?

Хотя для шаред памяти немного изменений надо будет внести

пет прожект. собственно для связи модулей в приложении)

все что касается потоков (uds, udp, tcp, stdio) - с

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

в русте, полагаю там сплошной unsafe