我知道共享内存和进程间通信的基础知识，但由于我的应用程序相当具体，所以我提出这个问题是为了获得一般反馈。
我在 64 位机器(MacOS 和 Win 64)上工作，使用 32 位视觉编码工具包。此时将工具包移植到 64 位是不切实际的，所以我有内存限制。
我正在开发一个必须能够快速删除(根据用户输入来回)高质量视频的应用程序。显而易见的解决方案是: 1 - 将其全部保存在内存中。 2 - 从磁盘流式传输。 目前将其全部放入内存需要将视频质量降低到 Not Acceptable 程度，而从磁盘流式传输会导致擦洗在加载时挂起。
我目前的思路是运行一个master和多个slave程序。每个从机将视频的一段加载到内存中，当主程序需要加载视频的不同部分时，它会向从机请求该数据并将其传输过来。
我的问题是，执行此操作的合适方法是什么？ 我怀疑共享内存不允许我突破我的应用程序当前存在的 32 位内存限制。我可以做像管道一样简单的东西，但我想知道是否还有其他更合适的东西。
理想情况下，此解决方案是 Mac/Win 可移植的，但由于最终解决方案必须驻留在 Windows 盒子上，我将选择 Windows 解决方案。而且越简单越好，因为我不想在这上面花费数周的开发时间。
提前致谢。
最佳答案
我猜您正在(或至少可以)使用带有 64 位操作系统的 64 位机器，尽管将所有代码移植到 64 位是不切实际的。我还假设您的机器有足够的可用内存来保存您关心的数据——真正的问题是如何从 32 位代码访问足够的内存。
如果是这样，那么我会查看 Windows 的地址窗口化扩展 (AWE) 函数，例如 AllocateUserPhysicalPages和 MapUserPhysicalPages .它们的工作方式有点像文件映射，只是当您将数据映射到您的地址空间时，它已经在物理内存中，而不是必须从磁盘读取(即，映射要快得多)。
关于C++在32位应用程序之间传输大量数据以进行视频播放的方法，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13893639/