Re: [Vala] [Announcement] Vala will use GTask for async code instead of GSimpleAsyncResult if --target-glib=2.36 or greater is selected





----- Original Message -----
From: Michele Dionisio <michele dionisio gmail com>
Sent: Tuesday, 22 November 2016, 0:32
Subject: Re: [Vala] [Announcement] Vala will use GTask for async code instead of GSimpleAsyncResult if 
--target-glib=2.36 or greater is selected

few weeks ago I post bug:


https://bugzilla.gnome.org/show_bug.cgi?id=772084
With patch attached to solve a bug raised calling an sync function
that is not really asyncronous (with vala only is not possible to
create async code that is not asyncronous, but if vala call C code,
like gio, everything can happens)

somone think that is it convinent that I update my patch for the new code?


The code generator switch, --target-glib, defaults to 2.32 for current Vala. When this default is changed to 
2.36 or above then the old GSimpleAsyncResult will be removed. So, yes, all new patches targeting Vala's 
async code generation should use the GTask paths.

Vala annotates a function with .begin, .callback and .end when the function is marked as async. This can be 
used to create coroutines ( https://en.wikipedia.org/wiki/Coroutine ). The main example of this in Vala has 
been for a generator. The generator example is now a test case in Vala: 
https://git.gnome.org/browse/vala/commit/?id=6e89b7b5d8112925cb8f07234a85ea1dba1e32e6


The question is whether Vala should fully support such a use case. The mailing list thread you point to has 
the original poster concluding "I think such warning that code must be async in 100% cases should be 
explicitly added to the documentation." ( 
https://mail.gnome.org/archives/vala-list/2016-March/msg00024.html ).

The discussion in the bugzilla report for the GTask patch has some relevant discussion ( 
https://mail.gnome.org/archives/vala-list/2016-March/msg00024.html ). You should look at comments #13, #18, 
#19 and the patch to get the generator example working (comment #20).
I guess there are three possible solutions:
1. Treat it as a documentation bug and make it clear async code requires a GMainContext and to be used 
asynchronously to work reliably in all cases

2. Add warning / error to Vala (probably the flow analyzer) that code is not being used asychronously
3. Work on making Vala work robustly when co-routines are used, there are examples of attempts to use 
co-routines with GLib, see https://patchwork.ozlabs.org/patch/427187/

I hope this provides some context to frame the ideas behind your patch, but I personally don't have the depth 
of knowledge or understanding to thoroughly review your patch.

Thanks for you work on Vala,


Al


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]