[Stackless] stacklesslib.async

Kristján Valur Jónsson kristjan at ccpgames.com
Wed Sep 25 16:47:29 CEST 2013


Ok, I've now submitted it.
Stacklesslib.async has been revamped a bit.  It is now basically a module to support the "async" decorator and calling convention.
It relies on stacklesslib.futures for the future support.  "Task" has been removed, we now use the "future" nomenclature.
Still experimental, I want to see if this is a useful paradigm borrowing from C#

> -----Original Message-----
> From: stackless-bounces at stackless.com [mailto:stackless-
> bounces at stackless.com] On Behalf Of Kristján Valur Jónsson
> Sent: 25. september 2013 09:58
> To: The Stackless Python Mailing List
> Subject: Re: [Stackless] stacklesslib.async
> 
> 
> 
> > -----Original Message-----
> > From: stackless-bounces at stackless.com [mailto:stackless-
> > bounces at stackless.com] On Behalf Of Richard Tew
> > Sent: 25. september 2013 08:26
> > To: The Stackless Python Mailing List
> > Subject: Re: [Stackless] stacklesslib.async
> >
> > Other than that, there's a sense that you should merge in the 3.3
> > futures support into the Stackless 2.7+ and stacklesslib should be
> monkeypatching it.
> 
> 
> I'm not sure I understand what you mean, do you mean the regular 3.3.
> futures?
> 
> The stacklesslib.futures are deliberately stackless-like as they use channels
> and such features for switching.
> I don't think it is easy, or desirable, to may them interoperable with 'regular'
> futures that use condition variables and such.
> It _could_ be made possible by monkeypatching condition variables, but
> then we have the multiprocessing stuff...
> 
> In other words, it is not possible to use concurrent.futures.wait with
> stacklesslib.futures, and vice versa.
> 
> So the prime idea here was to create an api that would be familiar top
> people, without promising full compatibility with actual modules.
> 
> 
> I must still admit that I find the futures api a bit awkward.  Particulary the use
> of an enum for futures.wait() is very un-pythoninc.  The lack of "attributes"
> on futures.  And the executor.map() being the only way to launch futures in
> parallel is akward.  We aim to put this to practical use with stackless in-house
> and we'll see what real-world use cases come out of that :)
> 
> K
> 
> 
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless





More information about the Stackless mailing list