Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Feature Request: Provide non-throwing methods to open/create shared_memory_object

Abierto
#151 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
cpp
Área
operating-systems

Línea de trabajo

Comience leyendo la API de shared_memory_object y el código referenciado de managed_open_or_create_impl.hpp, especialmente las líneas 285-338. Determine cómo las operaciones de creación/apertura que no lanzan excepciones pueden indicar si se creó un segmento, incluido un tamaño solicitado en POSIX y Windows. Se considera terminado cuando la API admite el caso de uso de sincronización sin excepciones en los constructores y distingue entre creación y apertura.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

My use case is as follows. I need to synchronize multiple processes or threads initializing a shared memory region. No select process can be considered the "master", so it is not known which of the processes will actually create and initialize the shared memory object. The natural solution would be to construct shared_memory_object(open_or_create), but this introduces a problem that the caller doesn't know whether the shared memory was created or an existing region was opened. This is important to later decide whether the caller should resize the region to the desired size and initialize the contents or try and adopt the existing one. (Testing the region size for 0 is not safe because it introduces a race condition.)

The current API does not provide a way to implement this efficiently. It is possible to implement a loop trying to construct shared_memory_object(open_only) or shared_memory_object(create_only), but the constructors throw on failure, which is unnecessary overhead and awkward to use in the caller. Indeed, you have implemented exactly that here. It would be better to have a set of methods in shared_memory_object that allow to create or open the shared memory and able to report the result without throwing - for example, through an error_code argument.

Also, please consider adding a way to create a shared memory segment of a given size. On POSIX, this would allow the aforementioned loop to be implemented in Boost.Interprocess instead of user's code. On Windows, CreateFileMappingW already accepts the desired size. This new API would also have to provide a result so that the caller knows whether a new segment was created or not.

Lenguaje dominante
C++
Estrellas
185
Forks
131
Sin PR fusionados en 30 d

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de boostorg/interprocess

Todos los issues de boostorg/interprocess

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.