Can a redistribution of PyFrameObjects-in-and-out be a good implementation of continuations?

Question

I'm interested in sequels , particularly in the Python C-API. From what I understand, the nature of continuations requires not abstracting the low-level calling conventions in order to manipulate the call stack as needed. I was fortunate enough to meet several examples of these scattered here and there . In a few examples that I came across, this abstraction is done using smart C (with environmental assumptions) or a custom assembly.

However, what is cool about Python is that it has its own interpreter stack, consisting of PyFrameObject s. Assuming single-threaded applications at the moment, shouldn't it be enough just to enable and disable PyFrameObjects to implement extensions in the Python C-API ? Why do these authors even worry about low-level materials?

Answer 1

Generators work by controlling the stack (actually linked list) of frame objects. But this will only help for pure Python code. This will not help you if C code is running in your code. For example, if you are in C code inside an I / O procedure, you cannot modify the Python frame object to force execution to move to another location. To do this, you must be able to change the C stack. What packages like green do for you.