As I see it (from a first look), the primary issue from a design perspective is to have all the Python threads synchronously access only one running scs instance. It is unclear if scs itself has any locking or design decisions around concurrency.

For the bindings here, it should mean introducing an instance-level lock within the SCS struct.

The standard TODOs for adding free-threading support are in two phases, the first of which is a baseline consisting of the following tasks:

• Run the test suite with pytest-run-parallel to find potential issues, and fix them.
• Run the test suite under ThreadSanitizer. If possible, depends on how many dependencies there are and if they run under TSan.
• Add cp313t-* to CI to build free-threading wheels.

The next phase is a bit more invasive, and it involves a single task:

• Audit Python bindings and declare them free-threading compatible (xref https://py-free-threading.github.io/porting/#updating-extension-modules).

For more details, please see the suggested plan of attack in the py-free-threading guide. The two phase approach is discussed in explosion/cymem#47 (comment) and gorakhargosh/watchdog#1105 (comment).

Note that this is the first time I've looked at this repo, so I might be
missing known issues or code that needs closer inspection. Any suggestions here
will be very useful.

Let me know if I ought to hold off for any reason.