Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for Python 3.10 #238

Merged
merged 3 commits into from May 6, 2021
Merged

Add support for Python 3.10 #238

merged 3 commits into from May 6, 2021

Conversation

jamadden
Copy link
Contributor

@jamadden jamadden commented May 5, 2021

Fixes #236 and fixes #237 and fixes #240

Locally, the python.org installer for macOS 3.10.0b1 is crashing on the test suite, but versions I've built myself are fine. I'm still trying to figure out what's going on.

Fixs #236 and fixes #237

Locally, the python.org installer for macOS 3.10.0b1 is crashing on the test suite, but versions I've built myself are fine. I'm still trying to figure out what's going on.
@snaury
Copy link
Contributor

snaury commented May 5, 2021

I suspect the "cframe" change to cpython might make greenlet very unstable and prone to crashes, and this might not be enough to fix it. The problem is that cframe pointers are chaining stack objects, and due to greenlet switching the order of ceval exits might not match their chaining order order, breaking spectacularly as greenlets rewrite stacks when switching (so when ceval of one greenlet restores cframe pointer it might point to another greenlet, which would have some unrelated data in that stack location until it is switched into).

I think you also need to "reset" cframe pointer for new greenlets (to root_cframe) and then save/restore it on every switch, this way greenlets would always have correct pointer chains local to that specific greenlet. I'm not sure how it might break tracing though, probably the "use_tracing" value would need to be copied across switches too.

@jamadden
Copy link
Contributor Author

jamadden commented May 5, 2021

Thanks!

I'm suspicious of that too. I suspect it's something like that that was causing the crashes locally, and I was surprised to find no crashes on CI. I'm working on trying to reproduce in a controlled way.

ETA: Other than with the python.org installer, I wasn't able to reproduce the crashes. But, by properly saving and restoring the cframe as part of the greenlet state, those crashes went away. Tracing seems unaffected.

… on 3.10.

This fixes the crashes that the python.org interpreter was having in the test suite.

This does not require a major version bump, even though the structure changed, because there hasn't been a 3.10 compatible release of greenlet yet.
@jamadden
Copy link
Contributor Author

jamadden commented May 5, 2021

gevent's generic test suite runs on Python 3.10 with this PR.

@jamadden jamadden merged commit ce53083 into master May 6, 2021
@jamadden jamadden deleted the python310 branch May 6, 2021 14:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add 3.10 for manylinux Greenlet fails to install on 3.10.0-beta1
2 participants