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]

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.

[bedevere-app]

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

[vstinner]

I have made the requested changes; please review again.

[bedevere-app]

Thanks for making the requested changes!

@markshannon: please review the changes made to this pull request.

[markshannon]

Can we please merge #139294 first before we add stuff on top of it?

[vstinner]

Can we please merge #139294 first before we add stuff on top of it?

Yes. I approved your PR.

[vstinner]

Can we please merge #139294 first before we add stuff on top of it?

PR gh-139294 has been merged. I rebased my PR on top of it.

I also modified my PR to use (base, top) internally instead of (start_address, size).

[vstinner]

Oh, TSan CI now fails with:

0:03:59 load avg: 5.34 [43/76/1] test_capi worker non-zero exit code (Exit code -6 (SIGABRT)) -- running (2): ...

python: Python/ceval.c:506: void tstate_set_stack(PyThreadState *, uintptr_t, uintptr_t):
Assertion `ts->c_stack_soft_limit < ts->c_stack_top' failed.

Fatal Python error: Aborted

[vstinner]

Oh, TSan CI now fails

Fixed.

[vstinner]

@markshannon: Please review the updated PR.

[markshannon]

Be aware that this is going to conflict with #140028

[markshannon]

Looks good, but should we wait for #140028?

[vstinner]

I created capi-workgroup/decisions#81 for the C API Working Group.

[vstinner]

Looks good, but should we wait for #140028?

I can wait until #140028 is merged. I will wait for C API Working Group anyway.

[encukou]

It might be better to merge this first, then update #140028 and ask @stefanor to test on HPPA.