Re: [Vala] Need help in debugging async code

[michele dionisio gmail com]

Vala implement async like in http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html

To avoid the limitation of stack usage (and to implement clousure) vala use the heap. Also the  state is in 
the heap. I have only add a check to check if a specific state is already executed. 

There is no multithead implication. It is only a more safe way to do the same thinks, but more safe.

About performance. Surellyif you develop a gui is not a problem. If you develop a web server that is managing 
a lot of asyncronous request the story is different (also because the glib mainloop is not so quick).

When I found few times I will try to write some test, but if in the mean times someone can test it I will be 
very happy. 

Il ven set 23 02:08:35 2016 GMT+0200, Nor Jaidi Tuah scrive:
> > Idle.add(myfunc.callback) is not good for 2 reason:
> > 1. performance. you go back to the mainloop
> > 2. Idle.add has to have less priority that the function that you have
> > to wakeup.
>
> Is the mainloop dispatch performance really
> inefficient? Just wondering here because I
> honestly do not know.
>
> If your patch changes or completely remove
> the async "barriers" then you might as well
> use multi-threading.
>
> Nice day
> Nor Jaidi Tuah
>
>
>
> PRIVILEGED/CONFIDENTIAL information may be contained in this message. If you are neither the addressee 
> (intended recipient) nor an authorised recipient of the addressee, and have received this message in error, 
> please destroy this message (including attachments) and notify the sender immediately. STRICT PROHIBITION: 
> This message, whether in part or in whole, should not be reviewed, retained, copied, reused, disclosed, 
> distributed or used for any purpose whatsoever. Such unauthorised use may be unlawful and may contain 
> material protected by the Official Secrets Act (Cap 153) of the Laws of Brunei Darussalam. DISCLAIMER: 
> We/This Department/The Government of Brunei Darussalam, accept[s] no responsibility for loss or damage 
> arising from the use of this message in any manner whatsoever. Our messages are checked for viruses but we 
> do not accept liability for any viruses which may be transmitted in or with this message.
> _______________________________________________
> vala-list mailing list
> vala-list gnome org
> https://mail.gnome.org/mailman/listinfo/vala-list