Ciertamente puede usar IPC para lograr esto, y hay muchos casos en que múltiples procesos tienen más sentido que un proceso multiproceso (al menos uno de los procesos se basa en código heredado al que no se pueden realizar modificaciones , que mejor serían escritos en diferentes idiomas, es necesario minimizar la posibilidad de errores en un proceso que afecta a la estabilidad de los demás, etc.) en un entorno compatible con POSIX, que haría
int descriptor = shm_open("/unique_name_here", O_RDWR | O_CREAT, 0777);
if (descriptor < 0) {
/* handle error */
} else {
ftruncate(descriptor, sizeof(Object));
void *ptr = mmap(NULL, sizeof(Object), PROT_READ | PROT_WRITE | PROT_EXEC, MAP_SHARED, descriptor, 0);
if (!ptr || ptr == MAP_FAILED)
/* handle error */ ;
Object *obj = new (ptr) Object(arguments);
}
en una proceso, y luego
int descriptor = shm_open("/the_same_name_here", O_RDWR | O_CREAT, 0777);
if (descriptor < 0) {
/* handle error */
} else {
Object *obj = (Object *) mmap(NULL, sizeof(Object), PROT_READ | PROT_WRITE | PROT_EXEC, MAP_SHARED, descriptor, 0);
if (!obj || obj == MAP_FAILED)
/* handle error */ ;
}
en el otro. Hay muchas más opciones, y no mostré el código de limpieza cuando terminaste, por lo que todavía deberías leer las páginas de manual de shm_open() y mmap(), pero esto debería ayudarte a comenzar. Algunas cosas para recordar:
/Toda la memoria que el objeto utiliza necesita ser compartida. Por ejemplo, si el objeto contiene punteros o referencias a otros objetos, o miembros dinámicamente asignados (incluyendo cosas como contenedores, std :: string, etc.), tendrá que usar la colocación nueva para crear todo (o al menos todo lo que necesita ser compartido con los otros procesos) dentro del blob de memoria compartida.No necesita un nuevo shm_open() para cada objeto, pero sí tiene que hacer un seguimiento (en el proceso de creación) de sus tamaños y desplazamientos, que pueden ser propensos a errores en casos no triviales y absolutamente tirando del pelo si tiene sofisticados tipos de autoasignación como contenedores STL.
Si algún proceso modificará el objeto después de haber sido compartido, deberá proporcionar un mecanismo de sincronización por separado. Esto no es peor que lo que harías en un programa multiproceso, pero tienes que pensarlo.
Si los procesos 'cliente' no necesitan modificar el objeto compartido, debería abrir sus identificadores con O_RDONLY en lugar de O_RDWR e invocar mmap() sin el indicador de permiso PROT_WRITE. Si los procesos del cliente pueden hacer modificaciones locales que no necesitan compartirse con los otros procesos, invoque mmap() con MAP_PRIVATE en lugar de MAP_SHARED. Esto reducirá en gran medida la cantidad de sincronización requerida y los riesgos de atornillarla.
Si estos procesos se ejecutarán en un sistema multiusuario y/o los datos compartidos pueden ser sensibles y/o esta es una aplicación de alta disponibilidad, querrá un control de acceso más sofisticado que el mostrado anteriormente . La memoria compartida es una fuente común de agujeros de seguridad.
@si tiene control sobre estos procesos, ¿por qué no convertirlos en hilos? Compartir la memoria es más fácil que Parece más sensato ya que todos tendrán un conocimiento adecuado de sus estructuras de datos internas (usted compartió el objeto) – Toad
Sí, creo que seguiré por este camino. Y le hice la pregunta para asegurarme de que no tengo una solución fácil con IPC. – flashnik