使用单个写入器增长 Boost.Interprocess 内存映射文件
Growing Boost.Interprocess memory mapped file with single writer
我的问题是关于在单个写入进程和多个 reader 进程的上下文中使用 Boost.Interprocess 增加内存映射区域。 是否可以使用作者的 managed_mapped_file::grow，假设 reader 不更新地图大小的变化是可以接受的？ 我的假设是reader 的地图将保持有效，然后当我需要它们从作者那里获取最新更改时，我可以使用更新后的大小重新映射 reader。这是正确的吗？
文档的 Growing managed segments 部分说：
Once a managed segment is created the managed segment can't be grown. The limitation is not easily solvable: every process attached to the managed segment would need to be stopped, notified of the new size, they would need to remap the managed segment and continue working. [...]
这让我觉得我可以 grow 只要我不介意 reader 没有立即更新。但是，文档继续说：
On the other hand, Boost.Interprocess offers off-line segment growing. What does this mean? That the segment can be grown if no process has mapped the managed segment. If the application can find a moment where no process is attached it can grow or shrink to fit the managed segment. [...] managed_mapped_file also offers a similar function to grow or shrink_to_fit the managed file. Please, remember that no process should be modifying the file/shared memory while the growing/shrinking process is performed. Otherwise, the managed segment will be corrupted.
这让我觉得我不能做我想做的事，但我不明白为什么它行不通。
让我们仔细区分 shared_memory_object（这确实是低科技且没有气势）和 managed_shared_memory/managed_mapped_file（两者都使用 segment_manager ).
您正在使用后者。
"assuming it's acceptable for the readers not to be updated of the change of the map's size":
我不明白这个假设如何成立。
托管段实质上构成了一个辅助内存堆及其相关的控制结构。
控制结构包含诸如 "heap" 的实际范围之类的细节是有意义的。由于控制结构在共享内存中，因此它们也必须在已映射到读取进程的部分中。
更改内存段的大小会更改该控制结构中的值，该结构从映射同一共享内存的所有进程中可见。这显然会对实际上没有足够的内存映射来满足新范围的进程造成严重破坏（最多导致页面错误）。
现在，我可以想象一个非常聪明的实现来规避对此类控制信息的需求（例如，带有标记值的经典空闲块列表）。但我不希望 Boost Interprocess 采取这条路线¹，并且您引用的文字强烈表明该设计不适合这种灵活性。
Is it OK to use managed_mapped_file::grow from the writer, assuming it's acceptable for the readers not to be updated of the change of the map's size?
不，这不行。
My assumption is that the reader's maps would stay valid, and then I could remap the readers with the updated size when I need them to pick up the latest changes from the writer. Is this correct?
/maps/ 会很好，毫无疑问（取决于 grow 是如何实现的，但我想我之前已经通过实验证实了这一点）。问题在于在顶部运行的 segment_manager 。这是一个会被混淆的。
¹ 纯 Fingerspitzengefühl
我的问题是关于在单个写入进程和多个 reader 进程的上下文中使用 Boost.Interprocess 增加内存映射区域。 是否可以使用作者的 managed_mapped_file::grow，假设 reader 不更新地图大小的变化是可以接受的？ 我的假设是reader 的地图将保持有效，然后当我需要它们从作者那里获取最新更改时，我可以使用更新后的大小重新映射 reader。这是正确的吗？
文档的 Growing managed segments 部分说：
Once a managed segment is created the managed segment can't be grown. The limitation is not easily solvable: every process attached to the managed segment would need to be stopped, notified of the new size, they would need to remap the managed segment and continue working. [...]
这让我觉得我可以 grow 只要我不介意 reader 没有立即更新。但是，文档继续说：
On the other hand, Boost.Interprocess offers off-line segment growing. What does this mean? That the segment can be grown if no process has mapped the managed segment. If the application can find a moment where no process is attached it can grow or shrink to fit the managed segment. [...]
managed_mapped_filealso offers a similar function to grow orshrink_to_fitthe managed file. Please, remember that no process should be modifying the file/shared memory while the growing/shrinking process is performed. Otherwise, the managed segment will be corrupted.
这让我觉得我不能做我想做的事，但我不明白为什么它行不通。
让我们仔细区分 shared_memory_object（这确实是低科技且没有气势）和 managed_shared_memory/managed_mapped_file（两者都使用 segment_manager ).
您正在使用后者。
"assuming it's acceptable for the readers not to be updated of the change of the map's size":
我不明白这个假设如何成立。
托管段实质上构成了一个辅助内存堆及其相关的控制结构。
控制结构包含诸如 "heap" 的实际范围之类的细节是有意义的。由于控制结构在共享内存中，因此它们也必须在已映射到读取进程的部分中。
更改内存段的大小会更改该控制结构中的值，该结构从映射同一共享内存的所有进程中可见。这显然会对实际上没有足够的内存映射来满足新范围的进程造成严重破坏（最多导致页面错误）。
现在，我可以想象一个非常聪明的实现来规避对此类控制信息的需求（例如，带有标记值的经典空闲块列表）。但我不希望 Boost Interprocess 采取这条路线¹，并且您引用的文字强烈表明该设计不适合这种灵活性。
Is it OK to use managed_mapped_file::grow from the writer, assuming it's acceptable for the readers not to be updated of the change of the map's size?
不，这不行。
My assumption is that the reader's maps would stay valid, and then I could remap the readers with the updated size when I need them to pick up the latest changes from the writer. Is this correct?
/maps/ 会很好，毫无疑问（取决于 grow 是如何实现的，但我想我之前已经通过实验证实了这一点）。问题在于在顶部运行的 segment_manager 。这是一个会被混淆的。
¹ 纯 Fingerspitzengefühl