[Stackless] Micro-threads: runAndContinue(), join()?

Just van Rossum just at letterror.com
Thu Nov 2 08:50:52 CET 2000

At 2:21 PM -0400 23-10-2000, Mike  Fletcher wrote:
>I've been getting a number of questions regarding use of micro-threads which
>seems to point up some things:
>	1) People are used to the threading module, where they start a
>thread and the start method immediately returns to the caller with the
>thread running in the background (which doesn't happen with micro-threads,
>as the scheduler isn't running yet (at least, as far as my understanding

Right, it can be annoying to explicitly having to start the scheduler.

>	To give immediate return functionality, my idea is that we could
>include a function "runAndContinue()" which encapsulates the rest of the
>programme as a continuation and then runs it as a micro-thread alongside the
>explicitly created ones.  Unfortunately, the naive implementation:

[ ... ]
I've been trying this as well, quite a while back, but also failed, even
after long discussions with Christian... I think the main problem is this:
when a continuation reaches the end of the bottom frame, it is the signal
for the interpreter to quit (causing the scheduler to end prematurely). We
obviously don't want that to happen, as the scheduler is not neccesarily
done at that point.

Hm, here's an idea of which I'm not sure I've tried it back then: how about
implanting a frame at the bottom of the stack, that jumps back to the
scheduler when returned to? (I'm not sure whether that's allowed, as it's a
"running chain". Maybe some more trickery is neccesary.)

Another issue: Raising SystemExit after run() is done seems the thing to
do, but might also be dangerous: what if the original main thread catches
it? What you really want to do is jump to the place after where you've
jumped to the scheduler at the end of the main thread... Should be doable,

>	2) Related (i.e. you would normally "join" the main thread to the
>important threads before the end of the proggy): We don't currently have
>"join" functionality (i.e. given a pointer to another micro-thread, wait on
>micro-thread exit/complete before continuing in the current micro-thread).
>Maybe a more generalised "messageHandler" system would be useful (register
>handlers for birth, death, suspension, etc of a thread).  Don't have time to
>look into it today, if someone else has an idea, let me know.

No idea just yet... A "death" callback seems useful for this particular


Stackless mailing list
Stackless at starship.python.net

More information about the Stackless mailing list