> ----- Original Message ----- > From: Michele Dionisio <michele.dioni...@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 _______________________________________________ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
