kquick
commented
4 years ago The Actor model is a concurrency model alternative to threads and processes. It's certainly possible to mix the two, but that can also lead to complications due to slightly different approaches to concurrency management. You might have better results sticking to just one model, although Thespian does support multi-threaded actors.
Since most conventional OS implementations provide a thread and process model, the Thespian Actor model is implemented "on top" of the underlying OS concurrency implementations; this can be contrasted with implementations like Erlang where the only concurrency functionality provided by the Erlang VM is the Actor model (although the VM itself must make the necessary adaptation to the services provided by the OS). Thespian currently provides two models: the simpleSystem model, which is essentially "cooperative scheduling" where all the actors run in the context of a single process, single thread, and variations of the multiProcess base where each actor is its own process.
The simpleSystem model is useful for testing and debugging, and simple separation of concerns programming, but doesn't provide the concurrency that is usually desired, so one of the multiProcess bases (usually multiprocTCPBase) should be used for enabling concurrency.
As you saw in the "In Depth" documentation, actors could conceivably be implemented as separate threads within the same process. In practical terms, when I've attempted this implementation in the past it has created significant concerns because threads are "leaky" with respect to the intents of the Actor model. Notably, each Actor is intended to run independently and not share any resources with other Actors unless those resources are explicitly passed via a message. The threads model is almost the inverse of this: all threads share common resources (memory, file descriptors, global variables, etc.). Additionally, IO operations are typically blocking and process global; there are ways to work around the blocking aspects of IO with more complicated implementations, but the process global aspects are more difficult to address. I have been unable to determine a good way to implement Actor isolation using threads. As a result, there is no current Thespian implementation that uses thread-based Actors.
My suggestion would be to try to use one Actor per camera, with some additional Actors to coordinate activities and perform higher-level processing (the Actor model often works best with single-concern implementations, so the camera-managing Actors should probably just manage the camera but not perform any other activities). I don't know what OS you are using, but under Linux, threads are essentially processes anyhow, so while there is some differences in resource consumption, it's probably not going to be significant. I have run hundreds of actors on "average" machine configurations without seeing significant difficulties. At least one advantage of this approach is that the Actor model will help keep the code concerns separated so that if the number of processes does become an issue and you need to try something like threading within the Actors, the code should already be self-contained and be easier to implement for a multi-threaded approach.
rbotafogo
Hello,
I´m trying to use Thespian with openCV and I would appreciate some advice on the architecture.
I need to develop a video processing application that works with more than 20 cameras simultaneously on a single machine. My idea was to create parallel actors that would create, let´s say, 10 new threads each, one to read each camera. So, for 20 cameras there would be 2 parallel actors and 20 threaded actors. After reading the data, each feed goes through a process of object counting and tracking using Tensorflow and will require more parallel and threaded actors (but this is not really relevant here).
According to the 'in_depth' manual: "There can be bases for implementing Actors as separate processes, or separate threads, or simply sequential execution", but I could not find any base for separate threads.
The alternative seems to be to create a separate process per camera, but I´m afraid this might consume to many processes... can this be an issue, considering that many more processes might be required for the whole system.
Do you have any advice on how to proceed? Thanks a lot!