archives

AsyncScala: DSL for coordinating asynchronous processes in Scala

I would like to present my project AsyncScala:

The project is based on Actor model, but there are some twists that it make different from most of the implementations of Actor model (save E from which I borrowed the core ideas and new EcmaScript effort by Mark Miller) that I know.

Composeable asynchronous components in one event loop

In most actor systems one asynchronous component = one event loop. And if take traditional receive operation, it knowns about all events and handles it. As result, the components could exchange only messages, and for shared memory interactions they have to stick to transactional memory and similar things.

However, there is another example of event loop programming. It is GUI system. In them, many asynchronous components share single event loop. In GUI event loop a wonderful thing happens. The handling of events is modularized. So different components handle each own events. Just consider what efforts would have been required, to build an actor that uses receive operation to handle events on GUI event loop. But with modularized event handling, event half-trained VB programmers could achieve this. And within event loops it safe to share memory.

Like E, AsyncScala also uses this approach, many DSL nice features would not have been implementable in a sane way without safe memory sharing.

Composeable asynchronous operations

This idea is combination of the idea of composeable asynchronous when operator and of idea of structured parallel programming in Occam.

The problem with traditional actor model is that event sends are considered as atomic operation. The event send and and received. And it is much easier than mutexes. However, event driven program usually requires inversion of control and becomes hairy with the time. The reason is that after receiving most of the events we have to restore the context and to correlate events to operations.

This is just like the situation was with gotos in sequential programming, that was nicely described by Edsger Dijkstra's in his letter "Go To Statement Considered Harmful" (there is a nice analysis if the letter). The solution that he has argued for is that flow of program text should correspond to the flow of control.

The framework extends this idea to asynchronous programming. In event-driven programming, one-way event send is an asynchronous equivalent of goto operator. So the framework firstly defines what is an asynchronous operation and than provides a number of operators that combine the asynchronous operations together. And these operators are built upon one-way message sends, like loops, function calls, and conditional operators in sequential and functional programming are built upon ifs.

So in the framework, the flow of program text much more closely corresponds to the flow of events in the system than in many other implementations of Actor model. The operators from framework are also described at here in more abstract form.

There are also Groovy and Java versions of frameworks in Git, but they need some fixing to shape them up.

By const at 2011-06-11 23:21 | LtU Forum | 5 comments | other blogs | 25131 reads