mmap 的可移植性如何？
我一直在考虑使用 mmap 来读取文件，并且想知道它的可移植性如何。 我正在 Linux 平台上进行开发，但希望我的程序能够在 Mac OS X 和 Windows 上运行。
我可以假设 mmap 在这些平台上运行吗？
I've been considering using mmap for file reading, and was wondering how portable that is.
I'm developing on a Linux platform, but would like my program to work on Mac OS X and Windows.
Can I assume mmap is working on these platforms?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
mmap()函数是一个POSIX 调用。它在 MacOS X（以及 Linux、HP-UX、AIX 和 Solaris）上运行良好。问题区域将是Windows。我不确定 POSIX“兼容性”子系统中是否有
_mmap()调用。它很可能在那里，但名称会带有前导下划线，因为 Microsoft 对名称空间有另一种看法，并认为mmap()会侵入用户名称空间，即使您要求使用 POSIX功能。您可以找到替代 Windows 界面的定义MapViewOfFile()以及另一个 SO 问题中关于性能的讨论 (mmap()与读取块）。如果您尝试在 32 位系统上映射大文件，您可能会发现内存中没有足够的连续空间来分配整个文件，因此内存映射将会失败。不要假设它会起作用；决定如果失败的话你的后备策略是什么。
The
mmap()function is a POSIX call. It works fine on MacOS X (and Linux, and HP-UX, and AIX, and Solaris).The problem area will be Windows. I'm not sure whether there is an
_mmap()call in the POSIX 'compatibility' sub-system. It is likely to be there — but will have the name with the leading underscore because Microsoft has an alternative view on namespaces and considersmmap()to intrude on the user name space, even if you ask for POSIX functionality. You can find a definition of an alternative Windows interfaceMapViewOfFile()and discussion about performance in another SO question (mmap()vs reading blocks).If you try to map large files on a 32-bit system, you may find there isn't enough contiguous space to allocate the whole file in memory, so the memory mapping will fail. Do not assume it will work; decide what your fallback strategy is if it fails.
内存映射文件的原理是相当可移植的，但是 Windows 上没有 mmap()（但存在像 MapViewOfFile() 这样的东西）。您可以查看 python mmap 模块的 c 代码，了解它们如何针对各种平台执行此操作。
The principle of a memory mapped file is fairly portable, but you don't have mmap() on Windows (but things like MapViewOfFile() exist). You could take a peek at the python mmap modules c code to see how they do it for various platforms.
如果您依赖将大量大文件映射到地址空间，则使用 mmap 读取文件是不可移植的 - 32 位系统很容易没有单个大的可用空间（例如 1G）可用的地址空间，因此 mmap 会失败通常用于 1G 映射。
Using mmap for reading files isn't portable if you rely on mapping large bits of large files into your address space - 32-bit systems can easily not have a single large usable space - say 1G - of address space available so mmap would fail quite often for a 1G mapping.
我考虑 UNIX 上的内存映射 io
由于不可用于交互式应用程序，
因为它可能会导致 SIGSEGV/SIGBUS
（如果文件同时被其他进程截断）。
忽略诸如 setjmp/longjmp 这样的病态“解决方案”
除了在收到 SIGSEGV/SIGBUS 后终止进程之外，我们无能为力。
新的 G++ 功能可将此类信号转换为异常
似乎主要针对苹果操作系统，
由于描述指出，需要运行时支持此 G++ 功能
并且在任何地方都找不到有关此 G++ 功能的信息。
我们可能还得等几年，直到 Windows 上出现类似的结构化异常处理，因为 20 多年来它已经进入了 UNIX。
I consider memory mapped io on UNIXs
as not useable for interactive applications,
as it may result in a SIGSEGV/SIGBUS
(in case of the file has been truncated meanwhile by some other process).
Ignoring such sick "solutions" as setjmp/longjmp
there is nothing one can do other than to terminate the process after getting SIGSEGV/SIGBUS.
The new G++ feature to convert such signals into exceptions
seems to be intended mainly for apples OS,
since the description states, that one needs runtime support for this G++ feature
and there is no information to be found about this G++ feature anywhere.
We probably have to wait a couple of years, until structured exception handling like it can be found on windows since more than 20 years makes its way into UNIXs.