The current implementation of the Swarm is contained in the SerializedSwarm functor in the cell/swarm.ml file. SerializedSwarm is a particularly inefficient implementation. The two most important aspects of the implementation are: 1) how does the Swarm parallelize the execution of the residents? and 2) what is the strategy for finding matches between the projections?
The SerializedSwarm creates a single thread, the runner thread, for the execution of all the residents. A single list of all the active residents is kept, and the thread iterates over the list, calling the click method of each resident in turn. When a resident returns false from the call, indicating that it has no further work to do, it is taken off the list. It can be added to it externally or through a match being found.
When the active list is empty (even if there are many residents), the runner thread blocks so that the CPU does not get into a tight loop. Any change to the active list wakes up the thread.
Another thread is created, the matcher thread, whose single job is to find matches between all the projections and execute them. In the SerializedSwarm's implementation, the matcher thread simply loops. At every loop, all the projections from all the residents are collected, the markers extracted, and the set of all pairs of markers is constructed. That set is then filtered by checking for matches, the ordered, and then bindings are attempted. The algorithm is completely memoryless, in that the entire set is reconstructed at every turn even if no residents are added or projections changed. However, the matcher thread will block if no matches are found, to prevent a tight loop. The thread will awaken if there is any change to the list of active projections.