бойкий имеет структуру данных под названием GAsyncQueue
, что позволяет осуществлять межпотоковую связь без семафоров / блокировок / и т. д. и даже делает тривиальной задачу реализации решения производителя / потребителя. Если два разных потока отправляют данные в GAsyncQueue
структура, push
функция внутренне реализует взаимоисключающий доступ к очереди; более удивительно, если поток вызывает pop
функции, и там нет никаких данных, вызывающий поток блокируется, пока некоторые данные не будут помещены в очередь другим потоком. Все это сделано потокобезопасным способом, прозрачно для разработчика.
Однако, насколько мне это нравится, эта библиотека была построена для C, и для языков более высокого уровня могут быть более подходящие альтернативы. В любом случае, я думаю об использовании glib, но странно использовать библиотеку C в коде C ++ …
Итак, вопрос: есть ли C ++ рекомендуемый эквивалент для glib? Более конкретно, есть ли более рекомендуемая библиотека C ++, которая обеспечивает те же функции, что и GAsyncQueue
?
Нет ничего плохого в использовании C в программе на C ++ (в конце концов, реализация C ++ в значительной степени основана на среде выполнения C, например, поддержка потоков C ++ 11 не может существовать без библиотеки pthread, по крайней мере на платформах, подобных UNIX®). Я бы определенно не выбрал инструмент / библиотеку только и целиком основываясь на языке, на котором он написан. Но если вам нужно использовать что-то еще, то glib не единственная библиотека в мире, которая обеспечивает асинхронную передачу сообщений (кстати, на самом деле это не похоже на поддержку IPC). Во всяком случае, вот список C ++ фреймворков, которые сразу приходят мне на ум (в случайном порядке, так же случайно, как мои мысли):
У каждого есть свои сильные и слабые стороны, и какой из них использовать, зависит от ваших требований. Я могу только порекомендовать вам обратить внимание на общую архитектуру приложения и на то, насколько хорошо асинхронная передача сообщений будет вписываться во все компоненты вашего приложения. Например, в более или менее сложных приложениях, которые включают в себя не просто передачу сообщений, такие асинхронные очереди часто интегрируются с используемыми механизмами уведомления о событиях (например, OSX построен вокруг Kqueue / НОД).
Надеюсь, поможет. Удачи!
Других решений пока нет …