# How to get an extension module working w/ free threading?

**URL:** <https://discuss.python.org/t/how-to-get-an-extension-module-working-w-free-threading/63653>\
**Category:** Python Help\
**Tags:** free-threading\
**Created:** [September 5, 2024, 9:33pm UTC](https://discuss.python.org/t/how-to-get-an-extension-module-working-w-free-threading/63653 "2024-09-05T21:33:49Z")\
**Posts on this page:** 1\
**Showing post:** 9

<div class="post-metadata">

**Author:** ![oscarbenjamin](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/oscarbenjamin/32/1209_2.png) [@oscarbenjamin](https://discuss.python.org/u/oscarbenjamin)\
**Post date:** [September 8, 2024, 4:43pm UTC](https://discuss.python.org/t/how-to-get-an-extension-module-working-w-free-threading/63653/9 "2024-09-08T16:43:23Z")

</div>

> [@Free-Threading Trove Classifier?](https://discuss.python.org/t/free-threading-trove-classifier/62406/24):
>
> The fact that there is no GIL doesn’t mean that everything must now be thread safe.  
> I think this is a point that should be remarked.
> 
> No one is expecting all features of all libraries to become thread-safe.  
> The standard `threading.Lock` is going nowhere; it is normal to expect that the user has to take care of concurrency issues.

There are different meanings of thread safe and of “safety” in general. Python can have thread-safety issues but is in general a _memory-safe_ language. The purpose of the GIL is to provide that memory safety. Python programmers are not generally used to segfaults or totally undefined behaviour which is the kind of thread-safe that applies when talking about extension modules and `Py_MOD_GIL_NOT_USED`.

The situation now is that with python-flint you can in one thread set an element of a matrix:

```python
M[0,0] = 2

```

In another thread you can compute the determinant of the matrix:

```python
d = M.det()

```

Currently the GIL ensures that these two operations take place one after another although the order is undefined. This means that you might get `d = 10` or you might get `d = 20` but exactly one of those possibilities will occur and Python won’t crash or anything.

Without the GIL what can happen is that `M[0,0] = 2` might trigger a call to `realloc` under the hood and then the code in the `det` function finds itself wandering around deallocated memory. This is now completely undefined behaviour: you can get pure garbage bytes from memory or you can get segfaults occurring either immediately or possibly much later as a result of memory corruption. It is impossible for me to give any real constraints on exactly what sort of bad things may or may not result from this although _usually_ the outcome is either that it happens to work fine or that you get a segfault.

There absolutely will be an expectation that extension module authors do not generally allow _that_ kind of unsafe behaviour regardless of whether the user is doing something that clearly involves data races. For now though free-threading is experimental and so I am happy to put out the wheels and let people try them even if I know that they might crash with segfaults. I also feel reassured that this is a reasonable approach since it is mentioned in the only document I have seen that provides meaningful advice for what extension module authors should do.

Does simply setting `Py_MOD_GIL_NOT_USED` and then uploading the wheels qualify for a “free-threading supported badge” even if it is expected that some multithreaded usage can result in completely undefined behaviour?

---

_[View the full topic](https://discuss.python.org/t/how-to-get-an-extension-module-working-w-free-threading/63653)._