We don't guarantee a specific order in this case, especially because they can be run in either order if there is more than one thread, but it is still useful to have a defined order for single-threaded task chains. To that end, tasks
are now run in the order in which they were added to taskMgr.add (in absence of any other ordering constraints).
Fixes#309
This introduces AsyncFuture as a new base class of AsyncTask. It's modelled after asyncio's Future class, except that it is thread-safe and you can use result() to block the current thread waiting for the future to finish (of course this is not necessary for use with coroutines).
AsyncFuture should be used for any operation that finishes in the future, to get the benefit of awaitability within coroutines as well as a standard interface for querying status and results of the operation as well as cancelling it. As such, it's been implemented in various places, including texture.prepare() and win.trigger_copy().
Note that AsyncFuture is intended to be used *once*; it cannot be used more than once. As an example of how this works, tex.prepare() will return the same future as long as the prepare isn't complete, but when it is done, subsequent calls to tex.prepare() will return a new future.
Sam Edwards
rdb
tobspr
David Rose