Linux ashmem 有什么特殊能力？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/9970858/
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
What special powers does ashmem have?
提问by Robert Martin
Can someone explain why ashmem was created?
有人可以解释为什么创建 ashmem 吗？
I'm browsing through mm/ashmem.cright now. As near as I can tell, the kernel is thinking of ashmem as file-backed memory that can be mmap'd. But then, why go to the trouble of implementing ashmem? It seems like the same functionality could be achieved by mounting a RAM fs and then using filemap/mmap to share memory.
我现在正在浏览mm/ashmem.c。就我所知，内核正在将 ashmem 视为可以进行 mmap'd 的文件支持内存。但是，为什么要去实施 ashmem 的麻烦呢？似乎可以通过安装 RAM fs 然后使用 filemap/mmap 共享内存来实现相同的功能。
I'm sure that ashmem can do more fancy stuff -- from looking at the code, it seems to have something to do with pinning/unpinning pages?
我确信 ashmem 可以做更多奇特的事情——从代码来看，它似乎与固定/取消固定页面有关？
采纳答案by Kaz
Ashmem allows processes which are not related by ancestry to share memory maps by name, which are cleaned up automatically.
Ashmem 允许与祖先无关的进程按名称共享内存映射，这些映射会自动清理。
Plain old anonymous mmaps and System V shared memory lack some of these requirements.
普通的旧匿名 mmap 和 System V 共享内存缺少其中一些要求。
System V shared memory segments stick around when no longer referenced by running programs (which is sometimes a feature, sometimes a nuisance).
System V 共享内存段在不再被正在运行的程序引用时仍然存在（这有时是一个功能，有时是一个麻烦）。
Anonymous shared mmaps can be passed from a parent to child processes, which is inflexible since sometimes you want processes not related that way to share memory.
匿名共享 mmap 可以从父进程传递到子进程，这是不灵活的，因为有时您希望进程以这种方式不相关来共享内存。
回答by jww
Can someone explain why ashmem was created?
有人可以解释为什么创建 ashmem 吗？
David Turner (a regular on Android NDK) answered this in Why was bionic/libc/include/sys/shm.h removed?:
David Turner（Android NDK 的常客）在Why was bionic/libc/include/sys/shm.h中回答了这个问题？：
... System V IPCs have been removed for cupcake. See bionic/libc/docs/SYSV-IPC.TXT for details.
In brief, System V IPCs are leaky by design and do not play well in Android's runtime environment where killing processes to make room for other ones is just normal and very common. The end result is that any code that relies on these IPCs could end up filling up the kernel's internal table of SysV IPC keys, something that can only safely be resolved by a reboot.
We want to provide alternative mechanism in the future that don't have the same problems. One thing we provide at the moment is ashmem, which was designed specifically for Android to avoid that kind of problem (though it's not as well documented as it should). We probably need something similar for semaphores and/or message queues.
... System V IPC 已被移除用于纸杯蛋糕。有关详细信息，请参阅 bionic/libc/docs/SYSV-IPC.TXT。
简而言之，System V IPC 在设计上是有漏洞的，并且在 Android 的运行时环境中不能很好地发挥作用，在 Android 的运行时环境中，杀死进程为其他进程腾出空间是正常且非常普遍的。最终结果是，任何依赖于这些 IPC 的代码最终都可能填满内核的 SysV IPC 密钥内部表，这只能通过重新启动才能安全地解决。
我们希望在未来提供没有相同问题的替代机制。我们目前提供的一件事是 ashmem，它是专为 Android 设计的，旨在避免此类问题（尽管它没有像应有的那样详细记录）。对于信号量和/或消息队列，我们可能需要类似的东西。
