ENH: Free threading support

[HaoZeke]

Closes #130.

Local tests via:

uv venv --python 3.13t .ftci
source .ftci/bin/activate
uv pip install numpy scipy pytest-timeout pytest-durations pytest-run-parallel
uv pip install -v .
uv run --no-project python -m pytest --parallel-threads=2 --iterations=2 -v -s --timeout=600 --durations=10 -m "not thread_unsafe" test

Basically follows the porting extensions advice:

• Vendored pythoncapi-compat
• Didn't rework Get* calls to use Get*Ref here since they're uses of argument parsing (xref C-API documentation)
• Locks access to the C library, using an instance lock and a global lock (for memory allocations)

EDIT: After the split into #132 and #133 to test this for now one needs to manually setup the pythoncapi-compat bit.

[HaoZeke]

Unlike #130, tests pass here https://github.com/bodono/scs-python/actions/runs/15374887139/job/43258511781?pr=1312

[ngoldbaum]

Some comments inline - I think you probably want to use the critical section API rather than adding a mutex to the wrapper object since the wrapper object extends PyObject and you need to call into the C API while working with it. Otherwise you're going to need to refactor things so that you don't have to call into the C API while holding the per-object lock.

[ngoldbaum]

Comments inline. I didn't read over the new tests since I'm not familiar with this library.

[ngoldbaum]

Does the GIL protect against the race you're worried about here? If not then you should lock on the GIL-enabled build too. It'd be nice to have an explicit test case for this fix if you don't already.

[HaoZeke]

The general idea here was to lock before Py_BEGIN_ALLOW_THREADS.

[HaoZeke]

Since its the initialization call, yes, it is covered by tests :)

[ngoldbaum]

Oh oops, I completely missed that this is happening inside SCS_init. In that case locking probably isn't necessary, unless it's somehow possible for two threads to simultaneously see the same SCS object before SCS_init returns an initialized object.

[HaoZeke]

I'm still a bit unclear about this. The guarantee with the lock is that there can be no two python threads trying to call scs_init (the external library) at the same time...

This is the general pattern of locks around calls to scs.

Under the free threading build without the lock isn't it possible for two threads to try to create scs objects at the same time thereby simultaneously calling into the external library? Or is the point that since the lock is on the object which hasn't been initialized yet it is meaningless anyway (or needs a global lock)?

[ngoldbaum]

So we need to make a distinction between scs_init and SCS_init. The latter is the tp_init slot for SCS_Type - it's the function that we're inside of in this comment thread.

A Python object is effectively thread-local while it's under construction. Said another way, there's no way for another thread to have a handle on the SCS instance before SCS_init completes.

[bodono]

Thanks for taking this on! Let me know when you think it is ready to merge!