windows mmap 的便携性如何？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2136527/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How portable is mmap?
提问by monkeyking
I've been considering using mmapfor 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.
我一直在考虑mmap用于文件读取，并且想知道它的便携性。我正在 Linux 平台上开发，但希望我的程序能够在 Mac OS X 和 Windows 上运行。
Can I assume mmapis working on these platforms?
我可以假设mmap正在这些平台上工作吗？
回答by Jonathan Leffler
The mmap()function is a POSIX call. It works fine on MacOS X (and Linux, and HP-UX, and AIX, and Solaris).
该mmap()函数是一个 POSIX 调用。它在 MacOS X（以及 Linux、HP-UX、AIX 和 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 considers mmap()to intrude on the user name space, even if you ask for POSIX functionality. You can find a definition of an alternative Windows interface MapViewOfFile()and discussion about performance in another SO question (mmap()vs reading blocks).
问题区域将是 Windows。我不确定_mmap()POSIX 的“兼容性”子系统中是否有调用。它很可能在那里——但名称会带有前导下划线，因为 Microsoft 对名称空间有另一种看法，并考虑mmap()侵入用户名称空间，即使您要求 POSIX 功能。您可以MapViewOfFile()在另一个 SO 问题（mmap()与阅读块）中找到替代 Windows 界面的定义和有关性能的讨论。
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.
如果您尝试在 32 位系统上映射大文件，您可能会发现没有足够的连续空间在内存中分配整个文件，因此内存映射将失败。不要以为它会起作用；如果失败，请决定您的后备策略是什么。
回答by MarkR
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.
如果您依赖将大量大文件映射到地址空间中，则使用 mmap 读取文件是不可移植的 - 32 位系统很容易没有一个大的可用空间 - 例如 1G - 可用的地址空间，因此 mmap 会失败通常用于 1G 映射。
回答by schlenk
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.
内存映射文件的原理是相当可移植的，但在 Windows 上没有 mmap()（但存在 MapViewOfFile() 之类的东西）。你可以看一看 python mmap modules c 代码，看看它们是如何为各种平台做的。
回答by schlenk
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.
我认为 UNIX 上的内存映射 io 不可用于交互式应用程序，因为它可能会导致 SIGSEGV/SIGBUS（如果文件同时被其他进程截断）。忽略诸如 setjmp/longjmp 之类的病态“解决方案”，除了在获得 SIGSEGV/SIGBUS 后终止进程外，别无他法。将此类信号转换为异常的新 G++ 功能似乎主要用于苹果操作系统，因为描述指出，需要此 G++ 功能的运行时支持，并且在任何地方都找不到有关此 G++ 功能的信息。我们可能需要等待几年，直到 20 多年以来在 Windows 上可以找到像它这样的结构化异常处理进入 UNIX。
