[Stackless] stacklesslib.async

Kristján Valur Jónsson kristjan at ccpgames.com
Tue Sep 3 15:25:32 CEST 2013

Thanks for your feedback.
The original "Task" interface in C# is perhaps not something we need to closely follow.
As I understand it, "task based asynchronous programming" came before the "await" semantics.
It makes a distinction between waiting for a result, and returning its value.  Although Wait will throw an exception if task execution throws an exception....
So anyway, I _think_ that in C# you
return t.Result

which separates these things awkwardly.

In my implementation of async.Task, I added a get_result() which combines the two.

I think it makes sense to create a module function, get_all_results() which operates on an iterable of Tasks. and returns a list of actual values, or raises an exception
This can be augmented with a "when_all_results()" function which returns a Task object.
Simlilarly "get_any_result()" returning an index and value, and "when_any_result"

This could then be used in preference to the Task-like WaitAll or WaitAny et al.

I also think I prefer module global functions to class methods, what do you think?

One interesting thing that .NET does, and these functions, is that they throw "AggregateException" wrapping the original error.  "await" does not.
Do you have any thought on that?



> -----Original Message-----
> From: stackless-bounces at stackless.com [mailto:stackless-
> bounces at stackless.com] On Behalf Of Richard Tew
> Sent: 2. september 2013 23:06
> To: The Stackless Python Mailing List
> Subject: Re: [Stackless] stacklesslib.async
> I think this general sort of functionality has long been needed in Stackless,
> and it brings up the old sawhorse of why are we not including stacklesslib in
> Stackless distribution.  But let's ignore that for now.
> I like the idea of having a standard well received API from another popular
> language, that people can just pick up and use with approximately same
> namespace - even if the coding standards for this specific API conflict with
> the rest of the package.
> That said I don't get the API.  It seems badly designed.
> To me, not having looked at the C# API much, I expect waitAll and waitAny
> should return the result of the tasks that completed with the index of each in
> the list.
> [ (0, text), ] = x.waitAny([ t1, t2 ])
> And whenAll and whenAny should imply there's a result, but not pull it.
> [ 0 ] = async.whenAny([ t1, t2 ])
> Then again, why return indexes.  That just means you have to waste time
> holding onto the original list, if you do not have a permanent one.
> But I think that this should not just handle tasklet completion, it should also
> handle tasklets producing results via channels.  In that case, it is useful to poll
> whether any tasklets have results, rather than waitX with a minimum
> timeout.
> I think that this should be in, but there surely can be a more natural fit.  And
> this might mean a requirement for lower level support.
> And having written all this, the elephant in the room is that I believe CSP,
> which Andrew Francis has long been advocating, is closer to what I think we
> need.  However, I've long had problems with using it ad hoc, as I think it is not
> that user friendly and is more theoretically balanced than functionally
> balanced.
> Cheers,
> Richard.
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless

More information about the Stackless mailing list