У нас получились два абсолютно независимых друг от друга приложения, которые знать ничего не знали друг о друге, да и разработка велась двумя группами программистов - плюсовики пилили одно приложение, питонисты - другое. Единственная логическая связь была посредством обсуждаемого IPC. То есть, писатель пишет в буфер, а кто именно оттуда будет читать - для него не имеет значения. Симметрично и читатель - он читает из буфера, и всё равно, кто туда пишет.
Спасибо за подсказку про pybind11, возьму на карандаш.
Специфика разработки для медицины очень сильно усложняет и затягивает процесс интеграции стороннего софта. Заказчик посчитал переход на стоковый питон 3.8 нецелесообразным, а тут целая опенсорсная либа.
Вот смотрите: у заказчика есть математик, который знает Питон и не знает C++. Математик пишет алгоритм, который решает задачу, но делает это медленно и не оптимально с точки зрения программиста. Заказчик обращается к нам и ставит задачу: сделать, чтобы быстро. И при этом он не готов и не хочет платить за портирование всей математики в плюсы, потому что математик вот он, у них, и дальнейшие правки без нас ему делать придётся.
Пробы различных MQ были направлены на сокращение времени разработки. Если есть существующее и отлаженное решение без фатальных недостатков - то зачем изобретать свой велосипед?
Чтобы не усложнять архитектуру и код без необходимости. Плюс к этому запись можно легко переключить в блокирующий режим, что было очень полезно во время тестов на производительность.
У нас получились два абсолютно независимых друг от друга приложения, которые знать ничего не знали друг о друге, да и разработка велась двумя группами программистов - плюсовики пилили одно приложение, питонисты - другое. Единственная логическая связь была посредством обсуждаемого IPC. То есть, писатель пишет в буфер, а кто именно оттуда будет читать - для него не имеет значения. Симметрично и читатель - он читает из буфера, и всё равно, кто туда пишет.
Спасибо за подсказку про pybind11, возьму на карандаш.
Специфика разработки для медицины очень сильно усложняет и затягивает процесс интеграции стороннего софта. Заказчик посчитал переход на стоковый питон 3.8 нецелесообразным, а тут целая опенсорсная либа.
Вот смотрите: у заказчика есть математик, который знает Питон и не знает C++. Математик пишет алгоритм, который решает задачу, но делает это медленно и не оптимально с точки зрения программиста. Заказчик обращается к нам и ставит задачу: сделать, чтобы быстро. И при этом он не готов и не хочет платить за портирование всей математики в плюсы, потому что математик вот он, у них, и дальнейшие правки без нас ему делать придётся.
Пробы различных MQ были направлены на сокращение времени разработки. Если есть существующее и отлаженное решение без фатальных недостатков - то зачем изобретать свой велосипед?
Чтобы не усложнять архитектуру и код без необходимости. Плюс к этому запись можно легко переключить в блокирующий режим, что было очень полезно во время тестов на производительность.