Free-threaded CPython support - follow-up

[NitayDariel]

Hi Jason,

Following up on our private email thread, opening this as a
public pointer to help orient the fix location.

The relevant files are:

src/greenlet/TThreadStateDestroy.cpp - MarkGreenletDeadIfNeeded()
src/greenlet/TUserGreenlet.cpp - g_switch(), check_switch_allowed()
src/greenlet/TGreenlet.hpp - MainGreenlet class fields

Fix direction and full details in the private email thread.
Happy to clarify anything here or privately.

Nitay.

[jamadden]

I don't see any need for any of this to be private. Using greenlets in free-threaded builds in ways not intended --- i.e., accessing the same greenlet from multiple threads at the same time --- can crash the process. This is simple thread safety bugs; they're not covered by test cases because that's not the indented use of greenlets.

I've identified at least six different ways that using greenlet objects from multiple threads can crash the process in debug builds of greenlet and CPython, either assertion failures, memory corruption detection, or invalid memory accesses.

Some of these issues were also identified by @devdanzin in https://gist.github.com/devdanzin/1f3d76d0fa083429906291901b99d7d5. I had considered not addressing them because they occur outside the standard use patterns of greenlets, but having looked more closely and determined how easy it is to crash or corrupt the process even with seemingly innocent patterns that did work previously (on GIL builds), I've changed my mind and will make changes.

[devdanzin]

NumPy simply has a "modifying an array from multiple threads is unsupported" rule. It's easy to get things to break if you don't follow it, but it doesn't make sense to try to cater to this kind of artificial usage scenario. Same seems to apply to greentlet, right?

[jamadden]

True enough. Still, it shouldn't be possible to crash the process by accessing the (read-only from Python) greenlet.dead attribute, and it currently is. Those are the kinds of things I'm looking at.