alua (active lua) is a Lua interpreter for the Symbian operating system that integrates Lua coroutines with Symbian active objects and the active scheduler.

alua allows you use active objects in a 'sequential manner'. Instead of trying to explain it lets dissect the example below.

``` package.loadlib("active_sock.dll", "1")() package.loadlib("active.dll", "1")()

function getURI (uri) s = socket.open() socket.connect(s, uri, 80) socket.write(s, "GET / HTTP/1.1\n\n")

repeat 
    data = socket.read(s)
    print(data)
    active.wait(1000)
until data == ""

socket.close(s)
active.stop()

end

getter = active.create(getURI) active.resume(getter, "www.symbian.com")

active.start() ```

The first part

package.loadlib("active_sock.dll", "1")() package.loadlib("active.dll", "1")()

loads the alua runtime and the active socket implementation (currently incomplete wrapper around RSocket and friends).

The next part that is interesting is this

``` getter = active.create(getURI) active.resume(getter, "www.symbian.com")

active.start() ```

active.create will create a new Lua coroutine running a single active object. The coroutine is running the function getURI.

active.resume will resume the Lua coroutine, effectively calling getURI with 'www.symbian.com' and giving the getURI function its own Lua stack.

active.start will start the active scheduler. This will 'block' the script at this point until a call to active.stop is called. This is similar as to CActiveScheduler::Start and CActiveScheduler::Stop behaves.

In the function below is where the awesomeness begins

``` function getURI (uri) s = socket.open() socket.connect(s, uri, 80) socket.write(s, "GET / HTTP/1.1\n\n")

repeat 
    data = socket.read(s)
    print(data)
    active.wait(1000)
until data == ""

socket.close(s)
active.stop()

end ```

the function getURI runs within its own little Lua coroutine run within an active object. Each call to socket.connect, socket.write, socket.read and active.wait are all asynchronous operations that will complete a TRequestStatus when completed. Calling any of these functions will yield the coroutine, only to have it resumed when TRequestStatus completes. It is not a blocking operation, if there were two of these 'active functions' running they would both interleave their execution the same way as active objects do. In fact they can also run together with other active objects created outside of the alua interpreter.

As you can see you can program active objects to look like sequential execution, no need to mess around with states in RunL etc.