Re: "previous frame inner to this frame" error when unwinding fibers

Andrey> Stackful coroutines I've ever encountered are very close to
Andrey> cooperative green threads - minus an underlying scheduler - in their
Andrey> implementation (separate stack + ucontext to store ABI-saved
Andrey> registers); a mental model is a bit different. I like the idea you
Andrey> proposed in that thread, with a caveat that the green threads would be
Andrey> more ephemeral. E.g. if I want to see the state of a coroutine, I'd
Andrey> spin up a green thread for it, switch to it and do whatever I'd
Andrey> usually do with a thread of execution; and then when I'm done I'd
Andrey> switch over to another thread and wind the green thread down so it is
Andrey> no more (or maybe I'd cache those threads and destroy them in bulk
Andrey> upon debuggee resume). As long as there is a Python API to manage them
Andrey> and as long as their model is similar enough to the OS threads' API,
Andrey> I'm sure we'd be able to code whatever solution suits one's specific
Andrey> needs.

Yeah, the API on the branch is very simple.  You can create a
GreenThread object, and this object supplies a few details: basically
registers and the thread name.  There's a way to indicate that the
thread has exited as well.  (I didn't get around to implementing a way
for 'bt' in a green thread to know when it should terminate.)

So, things like "frame view" could be rewritten in these terms, with the
idea being that the new green thread would simply be marked as exited
when the user switched away from it.  Coroutines could do the same, I
think.

Tom