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
>
_______________________________________________
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Reply via email to