Набросана программка: работа с портами и разные вспомогательные модули к ней. От простого плеера, до объемной текстовой логики с использованием sqlite и одновременным обменом данных по TCP/UDP. Все эти модули должны работать вместе и зависеть от результатов друг-друга. Пока есть 3 приложения, в которые разнес функции (одно под музыку, другое под ИК излучатель, третье под работу с контроллером). Все вроде бы как увесистые и в одну большую программу совмещать не хочется, но и при добавлении нового функционала единой системы, стает проблема, что число одновременно запущенных программок-помощников растет, а хорошо ли это? Контролировать их и соединять потоки данных между собой становится все запутаннее и сложней.

Пользовать dll - смысла не вижу, так как повторяющихся функций нет, и обхожусь мультиками. Тем более они висят на потоке приложения в любом случае.

Уже обостряется проблема с UDP между программками - пришлось увеличить число полузакрытых соединений в винде с 10 до 100. Может другой способ быстрого обмена данных есть?

Может пользовать фоновые программы или создавать сервисы? Все "модули" ресурсоемкие и с кнопочками разными - управляемые, в общем.
Смотрел всякие увесистые программные пакеты - куча dll и один exe. Как же поступать в случае с HiAsm?

Neo, современные программы очень часто работают как набор множества отдельных приложений, включая сервисы, сообщающихся различными способами. Оперативный обмен данными между ними - главная задача программиста. К сожалению, штатно пакет Windows серьёзно ограничен в межпроцессных коммуникациях, например, общие области памяти штатными компонентами не откроешь, то же касается и pipes.

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

tomas, зависит от объемов данных и допустимой задержки, чаще UDP значительно оперативнее, чем общие файлы и связанные с ними блокировки (конфликты доступа).

Да, было бы удобно читать данные прямо из общей памяти приложения. Но как на сегодня можно реализовать объединение кучки разнонаправленных приложений в одну сообщенную систему? Хочется взять теперь более конкретный "курс", уяснить важные моменты и дальше вести разработку по оптимальной системе, а не "лишь бы здесь работало, а там не глючило"

Те же UDP уже немножко настораживают тем, что заполняют системные ресурсы довольно серьезно. Даже 5 программок связать в обе стороны - 10 UDP, что весьма ощутимо. Если еще и перекрестно их соединить (программки), то количество UDP еще увеличится. Плюс еще к ним обмен данных с программкой-следилкой, за работоспособностью этой гоп-банды следить

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

Neo, в Windows есть много механизмов IPC (сообщения между процессами). Это и MailSlot, и DDE, и конечно UDP. Есть ещё общая память, но работа с ней в HiAsm невозможна без IC. Также для передачи небольших объёмов данных можно использовать messages (с кодами > WM_USER).

Neo, Вам уже намекнули - создаёте один хост-процесс (сервер), к которому подключаются все остальные, в качестве клиентов, и через него же и общаются между собой. Такое решение имеет интересный побочный плюс - приложения можно разнести по разным физическим ПК, даже не обязательно - близким географически, главное - видимость сервера для каждого из клиентов. Минус в оперативности в виду ограничения прямых коммуникаций между модулями. При правильном проектировании схема очень жизнеспособна и, кстати, популярна не одно десятилетие став живой классикой.

1nd1g0, я уж намек понял, даже в подсознании к нему и стремился раньше, но здесь не уясненный вопрос о способах передачи: UDP, MailSlot(совсем, кстати, не тестировал его на отказоустойчивость)? А само приложение-сервер должно нести только интерфейсную нагрузку и коммутацию программ-модулей? Я не претендую на один исчерпывающий ответ - наоборот, готов прислушаться к общему опыту.

Уместно ли вообще брать и делить функции одной системы на программки, и когда наступает порог оптимально отделять от программы модуль в отдельное приложение? Критерии веса, количества потоков или на личное усмотрение "мастера"?

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

Neo, всё это сугубо индивидуально, я, например, встречал даже активное использование временных веток реестра как обменника между программами. (вопреки распространённому заблуждению, рабочая копия реестра собирается в памяти, и работы с диском практически не происходит, хотя всё равно способ довольно эксремальный, но позволяет устанавливать коммуникации между очень и очень различными по архитектурам средами, например, скриптами, управляемым кодом и машинным кодом самой разной разрядности одновременно, вплоть до работающих под разными учётными записями и на разных уровнях системы безопасности).

Честно говоря, когда наступает момент возникновения таких вопросов, пора в серьёз задуматься - а предназначен ли HiAsm для таких вещей?

1nd1g0, за реестра - спасибо. Новшество для меня. Буду держать на всякий случай.
С HiAsm я многое (для меня) могу, а на голом языке я ноль, совсем без палки.
------------ Дoбавленo в 01.44:
И что лучше - много программок, но отдельно, или одна программа, но с кучей потоков?

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

Еще по теме: имея в программе хотя бы 1-2 параллельных потока с общими данными, нужно переводить все исполнение программы от системного потока в параллельные с расстановкой сейфмод? К этому выводу пришел после перечитывания справки по сейфмод: системный поток будет виснуть с сейфмод=Wait.

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

Кстати, это правильный перенос данных из системного потока в параллельный? code_26985.txt

Да, в целом - правильный. Wait гарантирует запись в память ценой ожидания, пока из неё произойдёт чтение. Но такой алгоритм постоянно (каждые 20 мс) считывает Memory параллельным потоком, даже если изменений ещё не производилось.

Один из интересных способов общения - назначение событий (Events) и реакция на них (WaitObject). Интересно, что события, по идее, могут обрабатываться не только потоками Вашего приложения, но и другими приложениями То есть регистрируем в системе событие - doCreate в Events, передаёте как параметр командной строки ObjHandle (его тип - Integer) всем аффилированным процессам или потокам. Потом, в цикле, те процессыпотоки делают doWait WaitObject. Если Вы куда-то записали что-то, через doSet поднимаете флаг события, и все, кто знал его ObjHandle, смогут соответствующим образом среагировать. Такая глобальная синхронизация потоковприложений. На другие учётные записи не действует, могут быть проблемы синхронизации с приложениями, запущенными под администратором и нет.

1nd1g0, спасибо, принцип я понял. На практике, правда, не сумел по примерам это применить (пока рановато видать).