[Vala] Coroutines / async methods - info needed for talk

["Sam Liddicott" <sam liddicott com>]

I've been accepted to give a talk at in April SambaXP 2009 on the topic
of programming Samba with Vala. The focus will particularly be on how
co-routines can simplify async programming.

It would help me very much if I was able to find out a little more on
the plans for co-routines/async method implementation of which it was
said recently that they were not a priority for Vala 0.6; and for which
little information or examples are available.

In this message I show what I've been able to find out - which I suspect
is not very complete - and then talk again about my hopes for vala
coroutines.

Specifically I'm interested in the various ways the "yield" keyword may
be used, and if/how continuations based on explicit callbacks rather
than events in a compliant event loop can be managed - or how firm Jürg
is that only gnome async programming should be supported.

I've come up with this Vala example to help me see what is going on:

using GLib;

int foo (int y) yields {
  int x;
  x=1;
  message ("hello");
  yield;
  y=2;
  message ("world");
  yield;
  y=3;
  message ("thats all folks");
  return 5;
}

void main () {
  foo.begin (0);
  message ("vala");

  var loop = new MainLoop (null, false);
  loop.run ();
}

But I think there is more that can be done, if only I knew what, and
what the underlying limits were.

I don't like the fact that foo.begin is required in the vala, but I
think that's a gnome thing and I can live with it (I was expecting that
any function that contains async-ish keywords would be generated the
async way, and that when called the async initialising entry point would
be used - but that's fine.

(I hope that a static class/interface can be provided for the underlying
async model so that rather than g_slice_new0 and
g_simple_async_result_new etc being emitted in the C code everywhere
there is vala-time control over the names of the functions that do these
generic operations, so that other async models can be supported)

Also, consider the generated C:

static gboolean foo_co (FooData* data) {
        switch (data->state) {

I suggest instead explicit callback entry points:

static gboolean foo_co_1 (FooData* data) {
        data->state=1;
        return foo_co(data);
}

..so that continuation addresses can be passed to libraries accepting a
callback function address.
Jürg, what are your feelings on this and how this would be expressed in
vala. I've suggested a few notations in the past.

Sam