Pensé que usaría Boost.Interprocess Message Queue en lugar de sockets para la comunicación dentro de un host. Pero después de investigarlo, parece que esta biblioteca, por alguna razón, evita la cola de mensajes POSIX (que es compatible con mi sistema Linux) y, en su lugar, se implementa sobre la memoria compartida POSIX. La interfaz es lo suficientemente similar como para que no adivine esto de inmediato, pero parece ser el caso.Boost Message Queue no está basado en cola de mensajes POSIX? Imposible seleccionar (2)?
El inconveniente para mí es que la memoria compartida obtenido a través de shm_open(3) no parece ser utilizable con select(2), en contraposición a las colas de mensajes POSIX obtenidos a través de mq_open(3).
Parece que la biblioteca de Boost pierde en este caso. ¿Alguien sabe por qué debería ser esto? Incluso si las colas de mensajes POSIX solo están disponibles en algunos sistemas, espero que Boost use esa instalación donde esté disponible, y la vuelva a implementar solo cuando sea necesario. ¿Hay alguna trampa del sistema POSIX que aún no reconozco?
Tenga en cuenta que en Linux, en lugar de utilizar un spinlock personalizado, utiliza los mutex compartidos y las variables de condición, que deberían ser casi tan eficaces como los mutex dentro del mismo proceso. Sin embargo, para seleccionar en los objetos 'boost :: interprocess', necesitará tener un subproceso que controle el objeto en cuestión y activar un fifo o eventfd cuando haya algunos datos en espera. – bdonlan
Aún así, no hay ninguna explicación en cuanto a WHY boost :: interprocess no usa posix mqueue cuando está disponible ... Hice una abstracción de mqueue que al construir en win32, mi abstracción usa boost :: interprocess :: mqueue y cuando se construye en Linux, mi abstracción usa posix mqueue. Eso fue fácil, es por eso que no puedo encontrar una razón por la cual boost :: interprocess no haga lo mismo. ¿Inmadurez? Algo que supervisé? –