AsyncScala is an implementation of Actor Model of concurrency. However, AsyncScala implements Actor Model differently from other Scala Actors.
The first thing to clarify is relationship to Scala actors. The AsyncScala Vat more or less corresponds to Scala Actor. And AsyncScala asynchronous are components that live inside the Vat and cooperatively handle events sent to actors. They are also based on Actor model, however with respect to Scala coarse-grained actors, they could be named sub-actors or micro-actors. This distinction is very useful to keep in mind, when you will be working with the framework. There is even an implementation of Vat over Scala Actor. However there are also other implementations (mostly ported from Java and Groovy version of framework), and these implementation will be possible converted to Actors in the future (currently it is not clear whether this is possible).
There is no hard opposition between these two models. These two models could be considered as complimentary. When you need a precise control on message dispatch and to work with actor queue as with whole, Scala actors might be a way to go. When you need to handle complex request/response scenarios, and it is important where message is dispatched rather than precise order, the AsyncScala components might be preferable. AsyncScala make different trade-offs than Scala actors, the precise control for message dispatch was traded for greater simplicity of programming and simpler composability.
And while root of these two frameworks is common (Actor model), Scala actors and this framework hav been inspired by different programming languages. The Scala actors were inspired by Erlang and this framework has been inspired by E programming language and by GUI frameworks that are based on event loops.
When reading about actors you have possibly noticed that might have been doing actor programming for a long time. This is a gui programming. The each program that interacts with widowing system could be seen as single actor with own inbox. That handles messages in order they have arrived. And that big actor also does some work using synchronous API and also by sending messages to other actors in the system.
The fact that GUI event loop provides some safety guarantees is long recognized by programmers. Java EventQueue.invokeLater(...) is one of most popular ways to resolve concurrency problems in the application.
This actor is so complex, that it would be impossible to create using single message handler (analogy to Scala actor receive operator). And this why we are able to assign different dynamic component that handle only own events from event stream, ignoring each others. However with scala actors, the entire actor should handle all messages in one place. So in Scala Actor framework there is one monolithic event handler. This works for simple actors, but it makes it difficult to create complex actors. And since the handler is monolithic, it is difficult to modularize event handling. Thus reducing possibility of reuse.
This framework allows creation of such sub-components in modular.
The framework uses the following fundamental concepts:
The next sections of the guide describe how these concepts play together.
