¿Es Boost IPC bueno?

Question

Mi opción predeterminada para el IPC multiplataforma sería impulsar, pero la vi criticada en dos foros diferentes cuando pregunté por ella y esto me preocupó. Tal vez esto fue simplemente una coincidencia, entonces, ¿cuáles son las ideas sobre impulsar IPC y elegir una biblioteca C++ IPC multiplataforma en general?

Para el desarrollo de Windows estamos usando VC++ 2008 como referencia.

edición: aquí es un ejemplo de los comentarios que he visto hecho (no se puede encontrar todos ellos en este momento):

de impulso, que es una porquería. Al menos en ventanas. Los Mutex no usan WinAPI, sino que crean su propia implementación basada en archivos (WinAPI = Kernel-Objects). Si su programa falla, los archivos no se eliminarán. La próxima vez que se inicie su programa no se puede crear el mutex, debido a el archivo existente.

Answer 1

De mi experiencia limitada con Boost.Interprocess, no tuve ningún problema importante pero realmente no puedo comentar sobre el rendimiento. Si bien es cierto que utiliza archivos creados fuera de la carpeta de su programa para hacer sus cosas, todos deben tener un mapa de memoria que niegue la mayoría de los problemas de rendimiento. En cualquier caso, cuando usa IPC siempre debe esperar una sobrecarga de rendimiento adicional.

En cuanto a las críticas que ha resaltado, es posible eliminar un mutex con nombre o cualquier otro recurso con nombre que haya quedado tirado por un proceso anterior (consulte la función estática remove(const char*)). Para ser justos, dependiendo de su aplicación, puede ser complicado usarla correctamente, lo cual no es algo con lo que tenga que lidiar cuando use la API de Windows. Por otro lado, la API de Windows no es portátil. Supongo que usan archivos (incluso cuando existe una mejor alternativa) para mantener la interfaz y el comportamiento de la biblioteca consistentes en diferentes plataformas.

De todos modos, los mutexes nombrados son solo una pequeña parte de lo que proporciona la biblioteca. Una de las características más útiles es que proporciona su own memory managers for the shared memory region que incluye STL allocators. Personalmente, me resulta más agradable trabajar con las construcciones de alto nivel que proporciona, entonces, la memoria en bruto.

---

ACTUALIZACIÓN: he hecho un poco más la excavación de la en la documentación Boost y me encontré con varias cosas tid interesantes:

This page da un poco más de detalle acerca de la aplicación y las actuaciones de la biblioteca, pero no incluye un fundamento de implementación.

This link indica claramente que su implementación mutex de Windows podría utilizar algún trabajo (versión 1.46). Si profundiza un poco más en la carpeta boost\interprocess\sync, verá dos carpetas más llamadas posix y emulation. Ambos contienen los detalles de implementación para la primitiva de sincronización.La aplicación POSIX para interprocess_mutex::lock es lo que se espera, pero la aplicación de emulación es bastante básico:

// Taken from Boost 1.40. 
inline void interprocess_mutex::lock(void) 
{ 
    do{ 
     boost::uint32_t prev_s = detail::atomic_cas32(const_cast<boost::uint32_t*>(&m_s), 1, 0); 

     if (m_s == 1 && prev_s == 0){ 
      break; 
     } 
     // relinquish current timeslice 
     detail::thread_yield(); 
    }while (true); 
} 

Así que por lo visto, dejaron de buscar la ayuda de POSIX y blobbed todo lo demás en una capa de emulación que utiliza la memoria mapeada archivos. Si desea saber por qué no proporcionan una implementación especializada de Windows, le sugiero que pregunte en la lista de correo de Boost (no pude encontrar nada en el documento).

Answer 2

Esto no es una respuesta directa a su pregunta, pero una alternativa: si tiene una opción en el entorno de desarrollo, entonces puede considerar Qt y the D-bus implementation in Qt.