[Stackless] [pypy-dev] The Work Plan Re: STM proposal funding

Christian Tismer tismer at stackless.com
Wed Apr 4 12:47:23 CEST 2012

On 4/1/12 11:23 AM, Armin Rigo wrote:
> Hi Andrew, hi all,
> On Wed, Mar 28, 2012 at 18:23, Andrew Francis<andrewfr_ice at yahoo.com>  wrote:
>>> Indeed, and it was around 2007, so I expect the authors to have been
>>> involved in completely different things for quite some time now...
>>> But I could try to contact them anyway.
>> Communications is good :-)
> I'm also thinking about writing a short paper collecting things I said
> and think on various blog posts.  A kind of "position paper".  What do
> others think of this idea?
>> My PyPy knowledge is still sketchy but I am changing that.  I do understand
>> the Twisted reactor model
>>   (thanks to my 2008 Pycon Talk) so I could follow discussions in that area.
>> Is this discussed on IRC?
> This is not discussed a lot right now.  But it is apparently
> relatively easy to adapt the epoll-based Twisted reactor to use the
> 'transaction' module.  (Again, this module is present in the stm-gc
> branch; look for lib_pypy/transaction.py for the interface, and
> pypy/module/transaction/* for the Python implementation on top of STM
> as exposed by RPython.)  This 'transaction' module is also meant to be
> used directly, for example in this kind of Python code:
>      for n in range(...):
>          do_something(n)
> If each call to do_something() has "reasonable chances" to be
> independent from other calls, and if the order doesn't matter, then it
> can be rewritten as:
>      for n in range(...):
>          transaction.add(do_something, n)
>      transaction.run()
> In addition, each transaction can add more transactions that will be
> run after it.  So if you want to play with lib_pypy/stackless.py to
> add calls to 'transaction', feel free :-)  Maybe it will show that a
> slightly different API is required from the 'transaction' module; I
> don't really know so far.
Hi A(rmin|ndrew),

it is funny how familiar this code looks, re-writing it in terms of
Stackless and tasklets:

     for n in range(...):

In addition, each tasklet can add more tasklets that will be
run after it. So if you (...)

Well, sure, it is not much more than a simple match, and the tasklets
are more like sequences of transactions, when they give up their
computation by stackless.schedule(), that adds them back to the pool.

Anyway, the underlying ideas have similarities that make me think a lot.

Thinking of Stackless, I was looking for a way to isolate tasklets in
a way to let them run in parallel, as long as they are independent.

In STM, independence is enforced, currently at a relatively high

If Stackless were able to provide some better isolation by design,
maybe there could be a hybrid approach, where most operations would
not need to rely on STM all the time?

Just rolling ideas out  -- Chris

Christian Tismer             :^)<mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121     :    *Starship* http://starship.python.net/
14482 Potsdam                :     PGP key ->  http://pgp.uni-mainz.de
work +49 173 24 18 776  mobile +49 173 24 18 776  fax n.a.
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
       whom do you want to sponsor today?   http://www.stackless.com/

More information about the Stackless mailing list