Iris Update

Today I finished off a couple more bug fixes for Iris. It now has the Coordination Arbiter which is similar to CCR's Arbiter.Interleave(). I'm quite happy I ventured down the path of doing GTask based on message passing. It's already been much easier to find bugs and triage them.

So like the previous post, you can use the coordination arbiter with the work stealing scheduler for extra hotness.

So what does the Coordination Arbiter do? It allows you to manage the delivery of messages (which culminate in a executable work-item) from multiple sources based on their concurrency requirements. The arbiter can control message delivery from 3 types of message receivers.

  1. Exclusive -- Only one of these can be executed at a time
  2. Concurrent -- Up to your desired concurrency level can be executed at a time
  3. Teardown -- Think of this as a dispose, everything going forward stops

No messages from different groups can be executed simultaneously. This can help you write your code without having to manage lots of locks (granted the arbiter has the locks, but at least you can tune in a single place).

Lets take a look at a quick vala snippet.

Arbiter.coordinate (
    // the "exclusive" receiver
    Arbiter.receive (
        null, // new WSScheduler (),
        (msg) => {
            if (msg.what == CONFIG_PORT)
                this.port = msg.get_int ("port");
    // the "concurrent" receiver
    Arbiter.receive (
        (msg) => {
            // process some http request or whatever
            // kids are doing these days
    // the "teardown" receiver

I always liked the gen_server behaviour in Erlang OTP. So my plan is to add IrisService which helps you write re-usable, concurrent, application services.

For those interested, the task implementation uses the coordination arbiter with a single exclusive receiver. It makes it much easier than managing locks within the task code.

Also, you can follow me on Twitter and fork the code on github.

-- Christian Hergert 2009-04-21

Back to Index