python-igraph icon indicating copy to clipboard operation
python-igraph copied to clipboard

Support for Python 3.14 Free Threading (no GIL)

Open InfiniteSamuel opened this issue 3 months ago • 1 comments

What is the feature or improvement you would like to see? Can I get a timeline for supporting Python 3.14 Free Threading (--disable-gil)?

Use cases for the feature igraph is a dependency in our project that has been migrated to Python 3.14t

References https://astral.sh/blog/python-3.14#free-threaded-python

InfiniteSamuel avatar Nov 14 '25 04:11 InfiniteSamuel

Unfortunately the internal C igraph library is not thread-safe so it's hard to make the Python interface thread-safe, which would be the first step towards officially supporting free-threaded Python.

There are two issues with the C core that need attention:

  1. There's a global stack of temporarily allocated objects that igraph uses to clean up after itself when an error happens (see details here). igraph itself can be configured in a way that it uses thread-local storage for the error stack so that would probably solve the issue but no one has really tested it yet.
  2. Running two igraph functions concurrently in two threads such that they both modify the same graph is definitely not going to work. This could probably be solved by having a mutex in each of the constructed Graph objects on the Python side and then locking the mutex when an igraph function is called on that graph (and unlocking it when the call returns), but since the code of the entire Python interface is hand-written, it would be very tedious and error-prone to implement this by hand.

All in all, I don't really see an easy way to add support for free-threaded Python in my spare time. There are two ways ahead:

  • We could try to apply for funding from somewhere to add support for free-threaded Python.
  • We could try to apply for funding to focus our resources on the development of https://github.com/igraph/python-igraph-ctypes , which would be an alternative Python interface to igraph with full type annotations, no C glue layer (we use ctypes instead), zero-copy NumPy support for data exchange and mostly auto-generated code. The fact that we auto-generate large parts of the bindings would mean that we could add support for locking by modifying the code generator instead of having to modify each of the exposed functions one by one.

ntamas avatar Nov 14 '25 11:11 ntamas