Replacing the Message Processing Loop

[awnns]

In Skick, actors have previously used a naïve approach to message processing. Each actor has its own message queue, and a variety of tasks that perform functions for that actor alone. This is not an ideal situation, since we end up spawning several tasks per actor. These tasks will spend most of their time idling, awaiting the queue or eachother, but will always consume at least two tasks for this purpose. A subsession will consume as many as six tasks (two for each actor and two for the websocket consumer). Each daemon will consume an additional two tasks. This way, the tasks add up quickly, allowing surprisingly few simultaneous passive actors to coexist in the system without performance degradation.

A solution for this would be to instead employ a task pool. In this version of the system, we would separate the current actor object (which mainly keeps track of information required to process messages) from the object that actually deals with the messages. We can then create several different types of executor classes and select whichever one we find most appropriate. A particularly useful one for when there are many passive actors is to have a task pool of, say, 1000 tasks. The task pool can then attach a task to the actor when it receives a message. This way, there would be no CPU overhead in adding additional passive actors. Certain particularly active or important actors, such as the special actors, could still be provisioned permanent tasks at the programmer's leisure.