Re: [Vala] Proposal for asynchronous DBus calls.

["Christian Hergert" <christian hergert gmail com>]

This isn't totally applicable, but I thought I'd mention it before too
much more async voodo.

I've been working on an asynchronous toolkit library for GObject so
that once we get "yield return/yield break" support I can implement my
ideas I posted earlier.

The library is called GTask and can be found on github[1].  For a
quick, totally out of context example:

var task = new Task (_ => {
    debug ("im in worker thread");
});

task.add_callback (_ => {
    debug ("im in main thread, by default");
});

task.add_errback (_ => {
    debug ("i can resolve an asynchronous error");
});

You can build complex callback/errback chains just like in Python
Twisted.  By default, the task scheduler will dispatch callbacks and
errbacks from the main thread to ease locking hell for GUI
programming.

[1] http://github.com/chergert/gtask/tree/master

Cheers
--
Christian Hergert <chris dronelabs com>

On Thu, Oct 16, 2008 at 11:44 PM, Sam Liddicott <sam liddicott com> wrote:
> If you seach recent vala posts by me, you'll see some discusion on this topic.
>
> I hope to be able to start coding something along these lines in a couple of weeks.
>
> My current plan is that such functions are generated as lamdas, with a set of wrappers for entry points.  
> There is no need for an async keyword.
>
> Callbacks can pass extra parameters.
>
> The vala notaton I now favour is:
>
> //async-able function
> Int func(int arg1) {
> ..
> return {
>  ...
>  Do-something(...,continue(int arg2, int arg3));
>  Return 1;
> }
> Use(arg3)
> ..
> }
>
> Continue() is a psuedo function which generates the address of a wrapper with the specified parameter list 
> which continues execution just after the return block.
>
> I don't know how GLibs g_idle works or fits in.
>
> Sam
>
> -----Original Message-----
> From: Yu Feng <rainwoodman gmail com>
> Sent: 16 October 2008 14:39
> To: vala-list <vala-list gnome org>
> Subject: [Vala] Proposal for asynchronous DBus calls.
>
>
> = intro =
> Vala has embedded DBus calls through its dynamic method mechanism.
> It is nice, but this is not yet the complete story of DBus.
>
> Aside from the sync calls, DBus can also make async calls. In an async
> call, the caller starts a DBus call on a DBusGProxy by
> dbus_g_proxy_begin_call, giving a callback to be invoked when the call
> is finished. In the callback, dbus_g_proxy_end_call is called to collect
> the 'out' args.
>
> Here is a tutorial on how to make asynchrous dbus calls.
> http://maemo.org/maemo_training_material/maemo4.x/html/maemo_Platform_Development/Chapter_05_Asynchronous_GLibDBus.html
>
> = current solution =
> In current vala, the related functions are exposed in dbus-glib-1.vapi,
> and in principle one can always write explicit code with these api to
> achieve an async call. lambda functions for DBusGProxyCallNotify can be
> used to to mitigate the discontinuity problem of async calls.
>
>
> = proposed solution =
> What if vala can also embed async DBus calls the same way as sync DBus
> calls?
>
> I have a vague, inchoate idea in mind. The newly introduced keyword is
> 'async', to describe an async function call.
>
> async Object . Method(method paramters) += callback;
>
> where callback is either a class/namespace method or a lambda function.
>
> Here is an example
>
> dynamic DBus.Object something;
> int int_param = 1;
> string string_param = "hello";
> async something.Method(string_param, int_param) += (rt1, rt2) => {
>    message("async call returns: rt1 = " + rt1.to_string() + "rt2 = " +
> rt2.to_string());
> }
>
> At the implementation level, valaccodedynamicmethodbinding has to be
> modified to generate appropriate wrappers for the callback function by
> invoking dbus_g_proxy_end_call.
>
> = Problems =
> Note: current vala doesn't support type signatures on parameters of
> lambda functions, but we can use a class member function(which has
> explicit parameter types) instead. Bug 511879 is related to this.
>
> The implication of asynchronous calls is a running MainLoop. this
> implication is not a new one, because we already need a mainloop for
> dynamic signals anyways.
>
> = Benifits =
>
> Embedding the support of async calls into Vala makes vala better
> suitable for writing async programs which do not block the UI for long
> time DBus calls.
>
> The 'async' keyword makes it extremely easy to modify existed sync
> program to async programs. In some cases if the return value is not
> interested, the modification is merely prefixing the 'async' keyword.
>
> = further =
> This can also be extended to non-dynamical methods, by GLib's g_idle
> mechanism.
>
>
> Yu
>
>
>
> _______________________________________________
> Vala-list mailing list
> Vala-list gnome org
> http://mail.gnome.org/mailman/listinfo/vala-list
>
> _______________________________________________
> Vala-list mailing list
> Vala-list gnome org
> http://mail.gnome.org/mailman/listinfo/vala-list