CODEWITHSUNDEEP
multithreadingipcactor
Citrullin
Citrullin

Reputation: 2321

Actor system with IPC and Threading

do I get this right? If I have an OS with IPC (inter process communication) and threading, I can simply use it as an actor model. So, I send and receive messages with IPC and start new actors as a thread (actually process, because I don't share the memory). Or do I miss some feature which is required by the actor model in order fit into the requirements?

Upvotes: 1

Views: 446

Answers (2)

Ivan Baidakou
Ivan Baidakou

Reputation: 783

Yes, you can create simple IPC-baced actor model, i.e. like ping-pong. However, there are a few issues:

  1. How do you plan to supervise spawned actors? I.e. either you are going to receive SIGCHILD, then supervisor (aka parent-process) will barely know about the reason of failure, or develop some more complex message from child-to-supervisor, i.e. describing the failure reason.

  2. Actors should communicate each other, i.e. there will be N-to-N logical connections. What IPC mechanism do you plan to use? It will be quite difficult to use shared-memory (as actors number is dynamic and configured at runtime) or use socket for each pair of actors. Sockets are also limited in a system, and they will be exhausted quite quickly (O(N^2), N - number of actors).

  3. How do you plan to do actor discovery? I.e. say, you need, an particular actor which provides particular service. Actor is identified via PID (system-defined, unpredictable from a program point of view). How an actor-X will be able to discover the PID of actor-Y, which you know, should provide some Y-service? You can pre-spawn all actors on the startup, and then you'll know all their addresses (PIDs), however how do you plan to dynamically spawn new actors on demand and let already-spawned actors know the new PIDs?

  4. In your system, it will be huge overhead on message passing between actors as it will be mediated via kernel (i.e. switch between processes), does not matter which IPC do you use. sobjectizer is able to pass 7 millions ping-pong messages per second (when they are on the same thread, and 2 millions is actors are on different threads).

I'd suggest you look at the existing C++ implementations for actor models, i.e. sobjectizer, caf or rotor as they already solve the described issues (as well as many others).

Upvotes: 1

Arnout Engelen
Arnout Engelen

Reputation: 6927

This is indeed possible: as you say all the building blocks are there.

Still, it doesn't seem to be a very good fit: when programming in the actor model, it is common create many actors, so actors should be 'cheap'. Unfortunately on most operating systems, processes are not cheap:

  • To start with, on a typical system the number of PID's is limited. Now you can increase pid_max to get around this up to a point, but this is already a sign that you're prehaps mis-using this tool
  • A process will likely have some state, so it'll need some pages of memory to store that state in. Even with smart copy-on-write tricks between processes, having many actors within a process will likely be more efficient compared to having one process per actor (unless you start sharing memory across processes, but you mentioned you don't want to do this, and indeed it seems difficult to keep safe)
  • Having so many processes means the kernel scheduler has to schedule them all. I would be concerned if it would not get overwhelmed by that: this would be a rather unusual workload, that typical schedulers are likely not optimized for. Traditional actor systems don't use one thread per actor, but instead keep track of message queues 'internally' and use a limited number of threads to service all actors. As long as actors don't block the threads and you have your number of threads close to your number of CPU's, this can be very efficient.
  • Failure handling (what if a process crashes?) seems tricky to handle across processes

So in summary, it's possible, but I'm not sure it would be a good idea. Would be interesting to see how it plays out when attempted, though!

Upvotes: 2

Related Questions