[Stackless] LLVM coroutine support [was: [LLVMdev] Proposal: stack/context switching within a thread]

Christian Tismer tismer at stackless.com
Wed Apr 14 13:37:39 CEST 2010

On 4/14/10 11:01 AM, Kristján Valur Jónsson wrote:
> Hello there.  Thanks for taking these thoughts into consideration.
> On the surface, it sounds reasonable to separate the stack copying and the context switching.
> There may be problems however.
> Take the case of 'swapcontext'.
> We cannot save the source stack until after the swapcontext() call, because only after this call do we have the context state to query for the stack position.  But any function call we perform after the swapcontext() may trample the unsaved stack, if the source and destination stack positions overlap.
> It would be better to query the "current" frame, so that we could do something like:
> extern void *base;
> extern void  *sourcestackpos, *sourcestack;
> extern void  *deststackpos, *deststack;
> extern context_t *sourcectxt, *destctxt;
> extern size_t sourcesize, destsize;
> void switch() {
> 	sourcestackpos = llvm.getstacktop();
> 	sourcesize = base-sourcestackpos
> 	memcpy(sourcestack, sourcestackpos, sourcesize);
> 	llvm.swapcontext(sourcectxt, destctxt);
> 	stackpos = llvm.getstacktop();
> 	memcpy(deststackpos, deststack, destsize);
> }
> I'll run this by Christian Tismer.  these posix "makecontext" functions sound useful, but the querying of the current stack pointer is missing (as is stack direction).  If we had those in posix, we could probably implement the hard switching / stack slicing using those primitives alone :)
> Of course, you can always "guess"  the current stack position simply by taking the address of an automatic variable.  You then hope that the call return address and other frame information are in the stack position 'above' that address.
The guessing is actually what Stackless does since years, and it
would be so much nicer to get rid of all that hacks.
The idea to let LLVM do this instead is just great. Getting
information like stack pointer is compiler and platform
dependent, and Stackless has a number of magic constants
for that, instead of a clear definition for every configuration.
That's the place where LLVM perfectly snaps in, taking that
burden away.

We will discuss this today in more detail.

It is great that this is being worked on. I would have
needed this ten years earlier, but better late than never :-)

cheers - chris

Christian Tismer             :^)<mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key ->  http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
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