Reputation: 2321
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
Reputation: 783
Yes, you can create simple IPC-baced actor model, i.e. like ping-pong. However, there are a few issues:
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.
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).
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
?
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
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:
pid_max
to get around this up to a point, but this is already a sign that you're prehaps mis-using this toolSo 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