也许 shmget 和 shmat 不一定是最适合您使用的接口.在我从事的一个项目中，我们使用内存映射的文件通过 C 和 Python API 提供对守护进程的访问，这为我们提供了一种访问数据的非常快速的方法

Perhaps shmget and shmat are not necessarily the most appropriate interfaces for you to be using. In a project I work on, we provide access to a daemon via a C and Python API using memory mapped files, which gives us a very fast way of accessing data

操作的顺序有点像这样:

The order of operations goes somewhat like this:

• 客户端发出 door_call() 告诉守护进程创建共享内存区域
• 守护进程安全地创建一个临时文件
• 守护进程 open()s 然后 mmap()s 那个文件
• 守护进程通过 door_return()
将文件描述符传递回客户端
• 客户端 mmap()s 文件描述符并将结构中连续放置的变量与该 fd 相关联
• 客户端在需要时对这些变量执行所需的任何操作.
• 守护进程从共享区域读取数据并进行自己的更新(在我们的例子中，将来自该共享区域的值写入日志文件).

• the client makes a door_call() to tell the daemon to create a shared memory region
• the daemon securely creates a temporary file
• the daemon open()s and then mmap()s that file
• the daemon passes the file descriptor back to the client via door_return()
• the client mmap()s the file descriptor and associates consecutively-placed variables in a structure with that fd
• the client does whatever operations it needs on those variables - when it needs to do so.
• the daemon reads from the shared region and does its own updates (in our case, writes values from that shared region to a log file).

我们的客户使用库来处理上述前 5 个步骤；该库带有 Python 包装器，使用 ctypes 来准确公开所需的函数和数据类型.

Our clients make use of a library to handle the first 5 steps above; the library comes with Python wrappers using ctypes to expose exactly which functions and data types are needed.

对于您的问题空间，如果只是写入输出队列的 python 应用程序，那么您可以跟踪仅在 python 应用程序中处理了哪些帧.如果您的 python 和 c++ 应用程序都在写入输出队列，那么这会增加您的难度，也许重构整个应用程序架构将是一项不错的投资.

For your problem space, if it's just the python app which writes to your output queue then you can track which frames have been processed just in the python app. If both your python and c++ apps are writing to the output queue then that increases your level of difficulty and perhaps refactoring the overall application architecture would be a good investment.