bpo-47215: Add undocumented, unstable FrameStack API for use by greenlets and similar libraries.

[markshannon]

Skipping news, as I want to keep this as low key as possible.
We want this for greenlets, we don't want it misused by other third party code.

@brandtbucher would this cover greenlet's needs?

https://bugs.python.org/issue47215

[jdahlin]

What about hiding this behind an ifdef, it would technically be an api break, but would make the intention clearer:

#ifdef _PYTHON_C_UNSTABLE_FRAMESTACK_API
...
#endif

[brandtbucher]

@brandtbucher would this cover greenlet's needs?

Sorry, I didn't get a chance to look at this too closely today. My plan is to attempt to modify my fork of Greenlet tomorrow to see how well it works with this branch (and then we'll have a patch we can upstream right away, too).

A few thoughts just from looking at this so far:

• I don't see much value in exposing a tunable chunk_size parameter, even internally.
• As I understand it, when it comes to the Python stack, Greenlet's needs are essentially limited to saving and restoring the state of an arbitrary thread.
• These steps also happen at different points: saving happens here, restoring happens here.
• To that end, I'm not sure if this init/swap/free model is a very good fit. A more useful API might be (roughly):
  • void *_PyThreadState_FrameStackSave(PyThreadState *tstate)
  • void _PyThreadState_FrameStackRestore(PyThreadState *tstate, void *saved)

We can also loop in the Greenlet maintainers and get their opinion on this. @jamadden?

[markshannon]

I don't see much value in exposing a tunable chunk_size parameter

The default size is 64k, which is fine for a thread, but quite large for a coroutine. It costs nothing to expose it.

The problem with a save/restore model is that it has too many states and error conditions. What state is the VM in after mutliple saves, with no restore? Or vice versa?

For performance reasons the frame stack struct needs to be embedded in the thread state, so we can't return a pointer to it.