我目前通过内存映射在多个进程之间共享数据（<1KB）。 1“作家”进程和多个“读者”进程全部mmap同一个文件。
目前阅读器进程需要不断检查更新。 读取器进程继续轮询mmap-ed区域以查看是否有新的数据被写入。
典型用法（和现有的实现） ：
“Writer”过程是一个logging器，它不断地以不规则的间隔附加新数据（每个新行）。 在任何给定的时间点，可能有一个或多个“读者”进程对“写入者”进程产生的任何新数据感兴趣。 而不是无限延伸的文件，它是一个循环缓冲区，即在固定数量的行之后，写入器循环并开始用新数据覆盖文件。 该文件中的头部字段跟踪最新数据的位置，即当前的“头部”。
总之，系统试图模仿msgsnd（）和msgrcv（）的语义，还有两个额外的注意事项：
支持多个“读者”
当“作者”发布单个味精时，应该发送多个通知，每个活跃的“阅读器”1个。
– >目前已经实现，因为每个“读者”不断轮询“头”字段，并在新的数据发生变化时读取。
持久性（文件支持）
如果任何“读取器”/“写入器”过程突然终止，恢复系统应该像重新启动过程一样简单。
– >当前实现的IPC共享数据保存在磁盘上的mmap-ed文件中。
会是什么？
– 快速 （低延迟）和
– 轻量级 （低cpu使用率）替代实现某种事件机制来通知读者进程每次mmap-ed区域由编写器进程修改？
注意 ：在读取器进程中，在mmap-ed文件中添加inotify监视器时，在编写器进程（即使在调用msync（）之后 ）更新mmap-ed内存时也不会导致任何事件。
在所有阻塞通信中，读者抓取数据，而其他读者不能读取它。
强硬的问题虽然…这些都是我得到…
（发布实际使用的解决方案以供将来参考）
使用这个补丁添加mmap-ed文件支持来通知 ，
sync()触发。