iris Python Bindings

I started to polish up the generated python bindings for iris today. They aren't perfect but starting to come together. Compare to the Vala example to see how it's similar.

  1. from iris import *
  2. s, e, c = WSScheduler(), Port(), Port()
  3. Arbiter.coordinate(
  4.     Arbiter.receive(e, lambda msg: doStateChange(msg), scheduler=s),
  5.     Arbiter.receive(c, lambda msg: doHttpRequest(msg), scheduler=s))
  6. # ...

Steve Bjorg of MindTouch also implemented a Work-Stealing scheduler for .NET in the MindTouch Dream library. I'm pretty sure it runs on Mono too. You can take a look at it here.

Comments closed | Trackbacks closed

Comments (7)

  1. Steve Bjorg wrote:

    Thanks for the mention. You’re quite correct. The StealingTreadPool is compatible with Mono. While the stealing thread pool is virtually lock free, I’m not sure if that’s a benefit on mono though unless it also has a thread-local heap it can allocate from (still trying to figure that out). The implementation follows generally the outline of .Net 4.0 work stealing scheduler as described here: http://bit.ly/pFEZT

    Wednesday, May 27, 2009 at 1:27 pm #
  2. chergert wrote:

    Does it need the thread-local heap for allocation of structures that exist in the queue? Could it be mitigated with a free-list per local-queue?

    Also, what happens if a neighbor steals a work-item, would this cause contention on free-ing the element back since it is owned by another thread? (I was worried about this myself, but hasn’t been a large enough % of cpu time to dig deeper).

    Wednesday, May 27, 2009 at 5:28 pm #
  3. chergert wrote:

    For future readers, if you want examples of iris, I just ported marina to use Iris instead of GTask.

    http://git.dronelabs.com/marina/commit/?id=e643048485268cd045ebc41a7a289889267cf72f

    Wednesday, May 27, 2009 at 8:38 pm #
  4. Bob Bobson wrote:

    Just so you know, in Python

    lambda msg: doStateChange(msg)

    returns a function that takes msg and calls doStateChange with it, so you might just as well pass doStateChange as the parameter to recieve, instead of creating a lambda. I guess you just copied and pasted the lamba keyword without knowing what it does. If you want to read more about it, go to http://www.diveintopython.org/power_of_introspection/lambda_functions.html

    Thursday, May 28, 2009 at 10:23 pm #
  5. chergert wrote:

    Hi Bob,

    I’m quite aware, it wasn’t practical code by any means. It was simply there so readers could see the parameters in a succinct code snippet.

    Friday, May 29, 2009 at 4:09 am #
  6. Bob Bobson wrote:

    No, no. What I’m saying is that where you have written

    Arbiter.receive(e, lambda msg: doStateChange(msg), scheduler=s)

    you could have just written

    Arbiter.receive(e, doStateChange, scheduler=s)

    so you have actually made the code harder to read. What you’ve written would work but it’s what we call “redundant”. Look up the documentation of the lambda keyword and you’ll see why.

    Friday, May 29, 2009 at 7:12 pm #
  7. chergert wrote:

    Right. Since doStateChange is a superfluous method, it would be necessary to show “def doStateChange(msg):” in the code snippet for readers to know the method took a single argument. I, honestly, felt that users would rather see fewer lines of code. If that is not the case, I can do that differently in the future.

    Friday, May 29, 2009 at 7:16 pm #