C++ 多个进程?

发布于 2024-07-30 10:26:57 字数 308 浏览 2 评论 0原文

我有一个由两个进程组成的项目,我需要以快速有效的方式在它们之间传递一些数据。

我知道我可以使用 TCP 来使用套接字来执行此操作,即使两个进程始终存在于同一台计算机上,但这似乎不是一个非常有效的解决方案。

我看到很多关于在 Linux 上使用“管道”的信息。 然而我主要希望它适用于 Windows 和 Linux(最好通过跨平台库),最好是类型安全的, 非阻塞方式。

另一件重要的事情是我需要支持整个应用程序的多个实例(即两个进程),每个实例都有自己独立的通信对象副本。

还有一种跨平台的方式来生成新进程吗?

I've got a project that consists of two processes and I need to pass some data between them in a fast and efficent manner.

I'm aware that I could use sockets to do this using TCP, even though both processes will always exist on the same computer, however this does not seem to be a very efficient solution.

I see lots of information about using "pipes" on Linux. However I primarily want this for Windows and Linux (preferably via a cross platform library), ideally in a type safe,
non-blocking manner.

Another important thing is I need to support multiple instances of the whole application (i.e. both processes), each with their own independent copy of the communication objects.

Also is there a cross platform way to spawn a new process?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

树深时见影 2024-08-06 10:26:57

看看 Boost.Interprocess

Boost.Interprocess 简化了常见进程间通信和同步机制的使用,并提供了多种机制:

  • 共享内存。
  • 内存映射文件。
  • 信号量、互斥体、条件变量和可升级的互斥体类型,将它们放置在共享内存和内存映射文件中。
  • 这些同步对象的命名版本,类似于 UNIX/Windows sem_open/CreateSemaphore API。
  • 文件锁定。
  • 相对指针。
  • 消息队列。

Boost.Interprocess 还提供了更高级别的进程间机制来动态分配共享内存或内存映射文件的部分(通常,分配固定大小内存段的部分)。 使用这些机制,Boost.Interprocess 提供了有用的工具来在共享内存和内存映射文件中构造 C++ 对象,包括类似 STL 的容器:

  • 在共享内存或内存映射文件中动态创建匿名和命名对象。
  • 与共享内存/内存映射文件兼容的类 STL 容器。
  • 类似 STL 的分配器,可用于共享内存/内存映射文件,实现多种内存分配模式(如池化)。

Boost.Interprocess 已在以下编译器/平台中进行了测试:

  • Visual 7.1 Windows XP
  • Visual 8.0 Windows XP
  • GCC 4.1.1 MinGW
  • GCC 3.4.4 Cygwin
  • 英特尔 9.1 Windows XP
  • GCC 4.1.2 Linux
  • GCC 3.4.3 Solaris 11
  • GCC 4.0 MacO 10.4.1

Take a look at Boost.Interprocess

Boost.Interprocess simplifies the use of common interprocess communication and synchronization mechanisms and offers a wide range of them:

  • Shared memory.
  • Memory-mapped files.
  • Semaphores, mutexes, condition variables and upgradable mutex types to place them in shared memory and memory mapped files.
  • Named versions of those synchronization objects, similar to UNIX/Windows sem_open/CreateSemaphore API.
  • File locking.
  • Relative pointers.
  • Message queues.

Boost.Interprocess also offers higher-level interprocess mechanisms to allocate dynamically portions of a shared memory or a memory mapped file (in general, to allocate portions of a fixed size memory segment). Using these mechanisms, Boost.Interprocess offers useful tools to construct C++ objects, including STL-like containers, in shared memory and memory mapped files:

  • Dynamic creation of anonymous and named objects in a shared memory or memory mapped file.
  • STL-like containers compatible with shared memory/memory-mapped files.
  • STL-like allocators ready for shared memory/memory-mapped files implementing several memory allocation patterns (like pooling).

Boost.Interprocess has been tested in the following compilers/platforms:

  • Visual 7.1 Windows XP
  • Visual 8.0 Windows XP
  • GCC 4.1.1 MinGW
  • GCC 3.4.4 Cygwin
  • Intel 9.1 Windows XP
  • GCC 4.1.2 Linux
  • GCC 3.4.3 Solaris 11
  • GCC 4.0 MacOs 10.4.1
无法言说的痛 2024-08-06 10:26:57

对于 IPC,Windows 仅支持命名管道就像 Linux 一样,只是管道名称由于差异而遵循不同的格式两个操作系统之间的路径格式。 您可以通过简单的预处理器定义来克服这个问题。 两个操作系统还支持管道上的非阻塞 IO 以及使用 select() 的 IO 复用。

For IPC, Windows supports named pipes just like Linux does, except that the pipe names follow a different format, owing to the difference in path formats between the two operating systems. This is something that you could overcome with simple preprocessor defines. Both operating systems also support non-blocking IO on pipes and IO multiplexing with select().

落花随流水 2024-08-06 10:26:57

普通的旧式 TCP 应该相当高效地工作; 据我了解,现代操作系统将检测 TCP 连接的两端何时位于同一台机器上,并通过快速、轻量级(类似管道)机制而不是通过普通的 TCP 堆栈在内部路由该数据。

因此,如果您已经拥有可通过 TCP 运行的代码,我建议您坚持下去,避免花费大量额外的开发时间而收效甚微。

Plain old TCP should work fairly efficiently; as I understand it, modern OS's will detect when both ends of a TCP connection are located on the same machine, and will internally route that data through a fast, lightweight (pipe-like) mechanism rather than through the ordinary TCP stack.

So if you already have code that works over TCP, I say stick with that and avoid spending a lot of extra development time for not much payoff.

尸血腥色 2024-08-06 10:26:57

这可能有些过头了,但您可以使用 Apache Portable Runtime; 这里是线程和进程函数。

It may be overkill, but you could use the Apache Portable Runtime; here are the thread and process functions.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文