[pypy-dev] Question about stm_descriptor_init(), tasklets and OS threads

[Andrew Francis]

Hi Armin:


________________________________
 From: Armin Rigo <arigo at tunes.org>
To: Andrew Francis <andrewfr_ice at yahoo.com> 
Cc: Py Py Developer Mailing List <pypy-dev at python.org> 
Sent: Tuesday, April 17, 2012 4:19 AM
Subject: Re: Question about stm_descriptor_init(), tasklets and OS threads
 
>I don't understand why at all, sorry. 

Please bear with me :-). I am in the same position now as I was in 2007 when I was trying to 
make Stackless interoperate with Twisted. A lot of silly questions. A lot of misconceptions.
A lot of looking at code to see how things worked. And some dusting off the old Operating 
System text books. 

> I will stick to my position that the Stackless module should be modified to use the transaction
>module internally, and that no editing of the low-level RPython and C
>code is necessary.  

Noted. Again, when you write a position paper, this would be listed as a fundamental
design principle. 

>It is possible that using the transaction module
>in pure Python from lib_pypy/stackless.py is not really working, in
>which case you may need to edit pypy/module/_continuation instead and
>call directly pypy.rlib.rstm in RPython.  But you definitely don't
>need to edit anything at a lower level.

I am trying to understand enough to get into a position to attempt an integration.

I will start with a Stackless bank account programme (I have written a version in RPython).  A
very simple programme to write. To make things interesting, my plan is to make one tasklet call 
schedule() hence causing a contention. It is important to note there is only one OS thread in action. 

However what is not clear to me and you are in a better position to answer is whether the
underlying low-level rstm machinery cares that it is user space tasklets, not OS threads that are the
units-of- execution that are causing a contention. 
 

Cheers,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20120419/1f0af59e/attachment-0001.html>