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

Kristján Valur Jónsson kristjan at ccpgames.com
Sat Apr 10 11:27:03 CEST 2010

> -----Original Message-----
> From: stackless-bounces at stackless.com [mailto:stackless-
> bounces at stackless.com] On Behalf Of OvermindDL1
> Sent: 9. apríl 2010 23:38
> To: The Stackless Python Mailing List
> Subject: Re: [Stackless] LLVM coroutine support [was: [LLVMdev]
> Proposal: stack/context switching within a thread]
> I was under the impression that Stackless Python had two forms of
> switching, hard and soft.
> Hard - Is as you described, it malloc's memory and copies a chunk of
> the stack and registers, just enough to represent the execution
> context.  It only uses hard switching when a C frame is on the stack.
> Soft - Every Python function is already fully enclosed, do not use the
> stack at all, so it just switches Python frames, it can only do this
> if *everything* on the stack is *only* Python frames, no C frames at
> all, this method however is a *great* deal faster then hard switching.
> Consequently, I see speed issues in the proposed implementation.  I
> already use LLVM for a stackless python'ish switching language, but I
> break things up into various function calls so everything is tail
> called, that seems to mitigate the main problems.  Any 'stack'
> variable that need to exist across calls are stored on a 'stack' that
> is passed from function to function for a thread of execution, fixes
> the speed issue in the makecontext style tasks, but requires a pass to
> go over your code to properly translate it into pure tail-calls (at
> least any calls that can 'halt' need to be made into proper
> tail-calls).

Yes, I was talking of hard switching.
Soft switching can be implemented regardless of the actual api used to do the hard switching.  It is a software solution that has nothing to do with the mechanisms being discussed.


More information about the Stackless mailing list