我有一个大文件，即 1TiB，作为“文件处理程序”拥有，允许 rwx------。我将其 mmap(2)-ed 到 64 位地址空间，并且一切正常。此文件由作为用户“filehandler”运行的进程处理。
其他进程请求此处理程序进程的服务，该处理程序作为文件处理程序以外的其他用户运行。他们通过 unix 套接字登录到处理程序。他们通过IPC规则进行通信，一切正常。
出于安全原因，不得将整个文件共享给请求者。文件中只允许请求者进程访问部分内容。
如果只与请求进程共享文件的允许部分，则将提供最佳性能。
例如，shm 为其他进程提供了访问段的 key ，这对请求者来说是一个实用的目标。
是否有任何方法可以仅将 mmap(2)-ed 空间的允许部分共享给任何已识别的进程，如 shm 技术？
最佳答案
Is there any way to share only the allowed parts of a mmap(2)-ed space to any processes identified like shm technology?
TL;DR:否。
更详细，
How to remap a file mmap(2)-ed in memory like shmget
mmap() 和 shmget() 没有可比性。更好的比较是一方面 shm_open()/ftruncate()/mmap() 的组合与 shmget()/shmat() 另一方面。这些是 POSIX 中用于创建带标签的共享内存段并将它们映射到进程地址空间的主要替代方法。你应该认识到 shmget() 的类比是 shm_open()，而 mmap() 的类比是 shmat().
现在，回到
Is there any way to share only the allowed parts of a mmap(2)-ed space to any processes identified like shm technology?
请注意，在上述两种情况下，提供不相关进程之间共享的是被映射的对象(共享内存段)，与 mmap() 本身无关。这同样适用于 mmap() 映射任何其他类型的对象，例如常规文件。它始终是映射对象，任何共享访问都通过该映射对象进行调解。它必须是这样的，因为内存映射是一个进程的属性——它本身不可共享。
您的设计要求文件处理程序进程充当数据的看门人，而不是允许客户端直接访问它。这很好，但它排除了客户端将文件映射到内存中的可能性。您可能会安排客户端通过任一类型的共享内存段访问数据，但这需要服务器将大文件中的正确数据复制到客户端的共享内存段中。这可能确实是需要考虑的事情，但您可以忘记服务器为客户端提供对文件的直接内存映射访问。
关于c - 如何像 shmget 一样在内存中重新映射文件 mmap(2)-ed，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/54696830/