Brandt Bucher <brandtbuc...@gmail.com> added the comment:
Fixing this actually ended up being a lot simpler than I anticipated (and it requires no changes on our end). All that's really required is saving and restoring: - tstate->cframe->current_frame - tstate->datastack_chunk - tstate->datastack_top - tstate->datastack_limit You can see my proposed fix for Greenlet here (this PR also contains some other 3.11-related fixes): https://github.com/python-greenlet/greenlet/pull/280 There is one weird edge case in Greenlet's use that I don't *entirely* understand, where it sometimes needs to update a thread with a NULL frame (as discussed above). We need to replace the thread's datastack with *something* in this case: setting it to NULL crashes the interpreter when it tries to allocate frames later, but leaving it as-is puts us in a situation where two threads are sharing the same datastack (also a recipe for crashes). My solution is to set it to a statically allocated zero-size "dummy chunk" in this case. It seems to work fine, since the zero-size forces the interpreter to allocate a "real" chunk on the next frame push. If this solution seems too hack-y, a very simple change on our end could be to start treating NULL as a valid datastack value, and have the thread state check for it when pushing new chunks. That would make for a relatively clean upgrade path for libraries like Greenlet, and doesn't require adding any new APIs. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue46090> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
