budden писал(а):
Касаемо быстроты одного АП, вообще вот в линуксе есть много способов межпроцессного взаимодействия
и все они приходят к тому, что быстрее всего иметь разделяемую область памяти и API для работы с ней. что я, в принципе, и реализую, только без специальных трюков с системными вызовами (но с трюком бутстрапа нового псевдопроцесса, да; однако это чисто обероновский трюк, независимый от ОС).
budden писал(а):
Насчёт внезапного прихода GC не стоит особо обольщаться. Если у тебя есть N независимых "работяг", и к одному из них пришёл GC, то он на время GC ничего делать не будет.
это всё ещё более предсказуемо, чем многопоточный GC, который может прийти в любой момент. тут я хотя бы точно знаю, какие именно сущности взаимодействуют, и могу быть уверен, что больше в концерт никто не вмешается. если я во всех работниках заранее выделил память, и больше не — то я точно знаю, что нигде в цепочке не будет внезапного прихода GC, который возьмёт и стопнет мне весь мир.
budden писал(а):
Если ты построил из них конвейер, то будет задержка во всём конвейере. А дальше простой для меня пример цифровой музыкальной студии с плагинами. Суммарная задержка в тракте должна быть минимальной. 5 мс - это всё ещё повод для совершенствования. А количество операций над звуком от входа до выхода может достигать десятка (микширование и обработки). Если взять N ББЦБ и в каждом из них написать алгоритм со сборкой мусора, то это всё в целом работать не будет.
конкретно такую задачу я буду решать, когда она у меня возникнет. я ж не претендую на решение типа one size fits all. вполне вероятно, что я для чего-то подобного вообще не буду писать алгоритмы обработки на BBCB, а буду использовать BBCB чисто в качестве высокоуровневого клея. я не настолько фанатик, чтобы «или всё на BBCB, или ничего мне не надо!» ;-)
budden писал(а):
Кроме того, понадобится планировщик задач, команды типа ps и kill. В итоге всё равно получится A2 или другая операционная система :)
BBCB и есть операционная система. ;-) ну подумаешь, она пытается этот факт спрятать. честно говоря — не очень сильно и пытается.
budden писал(а):
Написать планировщик задач - непросто.
так мне не надо его писать, у меня для этого host OS есть.
budden писал(а):
В любом случае, процессы не будут полностью изолированными и нужно будет следить за тем, как они конкурируют за вычислительные ресурсы, управлять этой конкуренцией.
мне вполне достаточно того, что язык не позволит написать код, который нагадит в чужой горшочек. это обеспечивает достаточную изоляцию. приоритеты «потокам-процессам» спокойно назначаются через host OS. а управление ресурсами — это уже задача программиста. у меня будет механизм, который позволит использовать все ядра CPU, и простой API для обмена сообщениями — а остальное строится по необходимости поверх этого. нахождение таких «псевдопроцессов» в одном АП просто облегчает передачу между ними большого объёма данных (по сути, это сводится к передаче одного объекта-хэндла).