El objetivo final aquí es que me gustaría poder ampliar el tamaño de un segmento de memoria compartida y notificar a los procesos para reasignar el segmento después de la extensión. Sin embargo, parece que llamar a ftruncate por segunda vez en un fd de memoria compartida falla con EINVAL. La única otra pregunta que pude encontrar sobre esto no tiene respuesta: ftruncate falló en la segunda vez
Las páginas de manual de ftruncate y shm_open no mencionan la prohibición de la expansión de los segmentos de memoria compartida después de la creación; de hecho, parecen indicar que se pueden cambiar de tamaño a través de ftruncate, pero hasta ahora mis pruebas han demostrado lo contrario. La única solución que se me ocurre sería destruir el segmento de memoria compartida y volver a crearlo en un tamaño más grande, sin embargo, esto requeriría que todos los procesos que han mapeado el segmento lo desasignen antes de que el objeto se destruya y esté disponible para la recreación.
¿Alguna idea? ¡Gracias!
EDITAR: según lo solicitado como ejemplo simple
#include <stdlib.h> #include <stdio.h> #include <unistd.h> #include <fcntl.h> #include <sys/stat.h> #include <sys/mman.h> #include <sys/types.h> int main(int argc, char *argv[]){ const char * name = "testfile"; size_t sz = 4096; // page size on my sys int fd; if((fd = shm_open(name, O_CREAT | O_RDWR, 0666)) == -1){ perror("shm_open"); exit(1); } ftruncate(fd, sz); perror("First truncate"); ftruncate(fd, 2*sz); perror("second truncate"); shm_unlink(name); return 0; }Producción:
First truncate: Undefined error: 0 second truncate: Invalid argumentEDITAR - Respuesta: Parece que este es un problema con la implementación de OSX del estándar POSIX, el fragmento anterior funciona en un kernel GNU/Linux genérico 3.13.0-53 y probablemente otros, supongo.
Con respecto a su objetivo final, aquí hay una biblioteca de código abierto que escribí que parece coincidir: rszshm: memoria compartida segura para punteros de tamaño variable .