gh-139653: Add PyUnstable_ThreadState_SetStack()

[vstinner]

Add PyUnstable_ThreadState_SetStack() and
PyUnstable_ThreadState_ResetStack() functions to set the stack base address and stack size of a Python thread state.

• Issue: Python 3.14 stack overflow detection is incompatible with C++ Boost make_fcontext() coroutines #139653

---

📚 Documentation preview 📚: https://cpython-previews--139668.org.readthedocs.build/

[encukou]

This generally matches what I came up with :)

The start argument might be confusing, as the place usage grows towards.
Why not use bottom & top as in the internals?

[vstinner]

This generally matches what I came up with :)

Good!

The start argument might be confusing, as the place usage grows towards. Why not use bottom & top as in the internals?

APIs like make_fcontext() or sigaltstack() use void *stack_start_address and size_t stack_size.

pthread_attr_setstack() and pthread_attr_getstack() also use void *stack_start_address and size_t stack_size.

[vstinner]

I'm not sure of this name. Maybe PyUnstable_ThreadState_InitStack() would be more explicit?

[markshannon]

Reset is better, "init" implies you should only call it once.

[vstinner]

These assertions fail on WASI but I don't have time right now to investigate why.

[encukou]

Should it be possible to call PyUnstable_ThreadState_SetStack just before a stack switch, when the stack pointer is still in the old stack?

[markshannon]

As long as you don't make any C-API calls between the two operations, the order in which you stack switch and call PyUnstable_ThreadState_SetStack shouldn't matter.

[markshannon]

So, unless we specifically say that PyUnstable_ThreadState_SetStack() should only be called after the stack switch, we'll need to remove these asserts.

[vstinner]

cc @markshannon @zooba

[encukou]

On systems like musl that just set top to the current stack pointer, PyUnstable_ThreadState_ResetStack has two issues:

• calling it “often” will essentially prevent stack protection
• returning from a function that called it will get you past the top of the stack, which should be fine but isn't really tested.

Would it be better to save the results of the initial _Py_InitializeRecursionLimits on the thread state, and have PyUnstable_ThreadState_ResetStack return to that?

[markshannon]

The API looks good, but it can fail in a couple of ways.

[markshannon]

This is incorrect. You need to leave _PyOS_STACK_MARGIN_BYTES space.

Don't worry, everyone seems to get this wrong. If #139294 ever gets reviewed and merged, it should prevent that happening.

[markshannon]

This also won't work. We need to record the top of the stack when initially getting the stack limits, and use that instead of _Py_get_machine_stack_pointer() otherwise, we could continually lower the stack limits, so that they become invalid.

[bedevere-app]

When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.

[markshannon]

Is this necessary? A stack size of zero is no less valid than a stack size of one. Anything less than 2 * _PyOS_STACK_MARGIN_BYTES + enough_stack_to_do_something_with is useless, and enough_stack_to_do_something_with is hard to define.