windows - mmap 的便携性如何？

Question

我一直在考虑使用mmap文件读取，并且想知道它的便携性。我正在 Linux 平台上开发，但希望我的程序可以在 Mac OS X 和 Windows 上运行。

我可以假设mmap正在这些平台上工作吗？

Answer 1

该mmap()函数是一个 POSIX 调用。它在 MacOS X（和 Linux、HP-UX、AIX 和 Solaris）上运行良好。

问题区域将是 Windows。我不确定_mmap()POSIX“兼容性”子系统中是否有调用。它很可能存在 - 但名称将带有前导下划线，因为 Microsoft 对名称空间有另一种看法，并考虑mmap()侵入用户名称空间，即使您要求 POSIX 功能也是如此。您可以在另一个 SO 问题（与阅读块）中找到替代 Windows 界面的定义MapViewOfFile()和关于性能的讨论。mmap()

如果您尝试在 32 位系统上映射大文件，您可能会发现内存中没有足够的连续空间来分配整个文件，因此内存映射将失败。不要以为它会起作用；如果失败，决定你的后备策略是什么。

Answer 2

如果您依赖将大量大文件映射到地址空间，则使用 mmap 读取文件是不可移植的 - 32 位系统很容易没有一个大的可用空间 - 比如 1G - 可用的地址空间，所以 mmap 会失败通常用于1G映射。

Answer 3

内存映射文件的原理是相当可移植的，但是您在 Windows 上没有 mmap() （但存在诸如 MapViewOfFile() 之类的东西）。您可以查看 python mmap 模块的 c 代码，了解它们如何在各种平台上执行此操作。

Answer 4

我认为 UNIX 上的内存映射 io 不适用于交互式应用程序，因为它可能会导致 SIGSEGV/SIGBUS（如果文件同时被其他进程截断）。忽略 setjmp/longjmp 这样的病态“解决方案”，除了在获得 SIGSEGV/SIGBUS 后终止进程外，别无他法。将此类信号转换为异常的新 G++ 功能似乎主要用于苹果操作系统，因为描述指出，需要对此 G++ 功能的运行时支持，并且在任何地方都找不到有关此 G++ 功能的信息。我们可能要等上几年，直到像 Windows 一样的结构化异常处理可以在 Windows 上找到，因为 20 多年来它进入了 UNIX。