Такую архитектуру дизайнили лет 10 назад. В настоящее время (Reactive/Async/EventDriven) стараются делать просто 1 большой процесс который диспетчеризирует канал I/O и раздает вызовы бизнес-функциям. Или акторам как будет угодно. Вобщем если сведенья со всех датчиков вы получаете через один сетевой интерфейс и все 100 датчиков работают на одном сетевом протоколе - то вам имеет смысл подумать о таком дизайне.
2000 процессов выглядят трешово. Тем более что вы должны понимать что квантов времени им никто не даст одновременно. Всё равно внутри ядра они будут стоять в очередях.
Единственное пожалуй преимущество вашей архитектуры в том что можно стартовать и килять отдельно каждый процесс. Но является ли это таким уж полезным?
Алан Гибизов, я как раз говорил об улучшении ленивого генератора. Просто следущая итерация - поиск слов в словаре во много раз более затратная чем генерация. Тоесть нам в любом случае дешевле проверить несколько гласных букв и отбросить заранее запрещенные комбинации и подать на вход следующему узлу конвейера отфильтрованное слово. Поиск в глубину и если успешно - передаем кандидат-слово дальше.
Ах да. 4 согласных буквы. "Мкртчян" :) Непрокатило. Будем искать 6 букв.
Если изучать вопрос академически. То скорее всего можно. Я так думаю. Мы просто обсуждаем принципиальную возможность. И мне это обсуждать интересно. Как инженеру.
Но если обсуждать в духе - можно ли нагнуть государство (ведь оно такое лоховское) то я-бы не стал этого делать здесь по крайней мере. Это просто некрасиво по отношению к тому государству будь оно трижды неправо и некрасиво.
Надо будет создавать копию файла со вставленным номером. А потом оригинал удалять и переименовывать копию обратно. Ничего не поделаешь. Так с текстовыми файлами работают. Поточно.
Zuzzy_Brannigan, C++ не советую. Это крайне техничный язык, необходимость в котором часто преувеличена. Вы утонете в трюках которыми часто злоупотребляют C++ разработчики, но не получите достойного профита. Кроме того в языке много неспецифицированного поведения. Это часто осложняет чтение кода.
Если отказаться от идеи запускать ваше приложение с плагином в одно процессе - тогда инструментарий расширяется до бесконечности. Вы можете рассматривать ваше приложение как сокет-сервер на определенном протоколе. И вобщем все ключевые слова такие как RPC вам в помощь. Надо только определиться с сетевым транспортом.
Похоже речь идет о преобразовании text-to-speech. Я-бы разделил на 2 части.
1) Преобразование текста в wave-form (почти все синтезаторы работают с волновой формой как с форматом выхода звука) $ espeak -f file.txt -w output.wav
2) Сконвертить waveform в mp3. $ lame output.wav ....
Средствами Python наверное можно сделать тоже самое если поискать native библиотеки для этого.
2000 процессов выглядят трешово. Тем более что вы должны понимать что квантов времени им никто не даст одновременно. Всё равно внутри ядра они будут стоять в очередях.
Единственное пожалуй преимущество вашей архитектуры в том что можно стартовать и килять отдельно каждый процесс. Но является ли это таким уж полезным?