> I haven't actually used async's, so I'm not sure of the specifics, but > I've used that structure to simulate pretty much exactly what you're > suggesting. In my case, each "async function" had an initialiser that > built and queued a structure with all the required variables, plus one > which was plugged into a switch/case statement containing the > individual segments of code, and updated to advance onto the next one > on the next resume. Yielding from within a loop got a little > interesting, and it was a pain to follow at times, but it worked. > Same pattern should work for you.
I'd done this sort of gymnastics before, "yielding" from a function containing a loop containing a recursive call, saving the "continuation" to a file, and able to resume when the application is restarted. But I prefer readable code rather than self torture. The async function is a great feature, allowing long-running computation to yield without having to obscure the logic with book-keeping matter. I hope vala will evolve further into a language where a continuation is a fully accessible object. It would be great if we can do something like these: x = async_function.begin () // get a handle to the continuation save_to_file (x); // useful for very very long computation read_from_file (out x); x.resume (); // resume our very very long computation x.cancel (); // a feature that answers my original query! hand Nor Jaidi Tuah _______________________________________________ Vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
