*** Bug 621542 has been marked as a duplicate of this bug. ***

Could you change the status to WIP?

my code is at: http://git.freesmartphone.org/?p=vala.git;a=shortlog;h=refs/heads/async

Async signal handlers for methods is already working

Do we need to store another function (finish) when passing delegates around? Is it sufficient to pass the _async, _finish, target and destroy notify?

O don't pass the _async function. only _finish. 
If you want to use the .callback function you might need _co, too. But you can use the methods .callback and GLib.AsyncReadyCallback if you need it.

(In reply to comment #4)
> O don't pass the _async function. only _finish. 
> If you want to use the .callback function you might need _co, too. But you can
> use the methods .callback and GLib.AsyncReadyCallback if you need it.

How are you supposed to call yourdeleg.begin () then?

that's the normal delegate

Is the async-new branch on fso ready for review or is this just part of what's needed?

Any progress on this? We could really use it in folks.

It would be nice way to make the spawning tasks in libgee nicer (in Future part of library).

For example if we want to call expensive_calculation and expensive_calculation2 in parallel and to their produce add the value of futures a and b.

Currently:

Future<double?> a, b;
Future<double?> c = task<double?>(() => {
    return expensive_calculation();
});
Promise<double?> promise = new Promise<double?>();
Future<double?> d = task<double?>(() => {
    double d_val =  expensive_calculation2();
    c.when_done((c_val) => {
        a.when_done((a_val) => {
            b.when_done((b_val) => {
                promise.set_value (c_val * d_val + a_val + b_val);
            });
        });
    });
});
return promise.future;

While with async delegates the following is possible:

Future<double?> a, b;
return task_async<double?>(() => {
    Future<double?> c = task<double?>(() => {
        return expensive_calculation();
    });
    double d_val = expensive_calculation2();
    double a_val = yield a.wait_async ();
    double b_val = yield a.wait_async ();
    double c_val = yield c.wait_async ();
    return c_val * d_val + a_val + b_val;
});

I plan to work on that feature this summer. Any prior work? Frederick's link seems broken.

I have uploaded our Vala repository to https://github.com/freesmartphone/vala. The branch origin/playya/async contains e.g.

commit bfcbc0b26c94f8c61f91bd41dc23290536cc9dd9
Author: Frederik 'playya' Sdun <Frederik.Sdun@googlemail.com>
Date:   Fri Jan 28 15:43:34 2011 +0100

    Add support for async signal handlers

    Fixes bug 602594.

which might be interesting for you.

Note though that this work is over five years old... chances are many things have changed. For more questions, feel free to contact Frederik directly.

If you want me to test it by introducing feature in libgee fell free to contact me about WIP. It would be cool if the libgee started using the feature when it gets introduced to Vala.

(In reply to Maciej Piechotka from comment #12)
> If you want me to test it by introducing feature in libgee fell free to
> contact me about WIP. It would be cool if the libgee started using the
> feature when it gets introduced to Vala.

Sure, I will post update here for that purpose.

I'm on vacation until the 13 of June and then I'll look into it.

It might be worth the check the following post, it should give a good preview of the feature:

http://arteymix.github.io/2016/03/30/async-delegates.html

There's still an issue with how chaining would be done syntactically since anonymous function would not have access to 'name.callback'.

I like the idea to keep things in such a way that marking a delegate as asynchronous does not break API. Therefore no explicit 'async' keyword on the closure and more type inference ;)

It seems to be a WIP with possible API break, then tagged for Vala 2.0 and enhancement.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vala/issues/66.