具有IPC和线程功能的Actor系统

这确实是可能的：正如您所说的，所有构件都在那里。

不过，这似乎不太适合：在参与者模型中进行编程时，通常会创建许多参与者，因此参与者应该“便宜”。不幸的是，在大多数操作系统上，进程并不便宜：

首先，在典型的系统上，PID的数量受到限制。现在您可以增加pid_max来解决这个问题，但这已经表明您可能会误用此工具
一个流程可能会具有某种状态，因此它需要一些内存页面才能存储该状态。即使使用了流程之间的智能写时复制技巧，在流程中拥有许多参与者也可能会更有效率每个角色只有一个进程（除非您开始跨进程共享内存，但是您提到自己不想这样做，并且确实似乎很难保证安全）
拥有如此多的进程意味着内核调度程序必须对它们全部进行调度。我会担心它是否会被淹没：这将是一个非常不寻常的工作量，典型的调度程序可能没有针对其进行优化。传统的参与者系统不每个参与者使用一个线程，而是“内部”跟踪消息队列，并使用有限数量的线程来服务所有参与者。只要actor不阻塞线程，并且您的线程数接近CPU的数量，这将非常有效。
故障处理（如果一个进程崩溃了怎么办？）似乎很难处理整个进程

总而言之，这是有可能的，但是我不确定这是一个好主意。看到它在尝试时如何播放会很有趣！

是的，您可以创建简单的IPC角色模型，例如乒乓球。但是，有一些问题：

您打算如何监督产生的演员？即或者您将要收到SIGCHILD，然后主管（又称父进程）将几乎不了解失败的原因，或者从子到主管开发一些更复杂的消息，即描述失败原因。
Actor应该彼此通信，即将有N对N的逻辑连接。您计划使用哪种IPC机制？使用共享内存（因为actor的数目是动态的并且在运行时进行配置）或为每对actor使用套接字将非常困难。套接字在系统中也受限制，并且它们将很快耗尽（O（N ^ 2），N-角色数量）。
您打算如何进行演员发现？即例如，您需要一个提供特定服务的特定演员。 Actor通过PID进行标识（系统定义的，从程序角度来看是不可预测的）。 actor-X如何能够发现actor-Y的PID，您知道应该提供某些Y服务吗？您可以在启动时预先生成所有参与者，然后您将知道他们的所有地址（PIDs），但是，您如何计划按需动态生成新参与者，并使已经生成的参与者知道新的{ {1}}？
在您的系统中，参与者之间传递消息的开销非常大，因为它将通过内核（即在进程之间切换）进行调解，而与使用哪个IPC无关。 sobjectizer每秒能够传递700万个乒乓消息（当它们在同一线程上，而200万个参与者在不同线程上时）。

我建议您查看参与者模型的现有C ++实现，即sobjectizer，caf或rotor，因为它们已经解决了所描述的问题（以及许多其他问题）。