bpo-47215: Add undocumented, unstable FrameStack API for use by greenlets and similar libraries. by markshannon · Pull Request #32303 · python/cpython (original) (raw)
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
| @@ -364,3 +368,16 @@ typedef int (*crossinterpdatafunc)(PyObject *, _PyCrossInterpreterData *); |
|---|
| PyAPI_FUNC(int) _PyCrossInterpreterData_RegisterClass(PyTypeObject *, crossinterpdatafunc); |
| PyAPI_FUNC(crossinterpdatafunc) _PyCrossInterpreterData_Lookup(PyObject *); |
| /* UNSTABLE API for stackful coroutines. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 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_sizeparameter, 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?
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.