# Is Free-Threading Our Only Option? **URL:** \ **Category:** Core Development\ **Created:** [May 13, 2025, 2:28am UTC](https://discuss.python.org/t/is-free-threading-our-only-option/91775 "2025-05-13T02:28:59Z")\ **Posts on this page:** 1\ **Showing post:** 73
**Author:** ![a-reich](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/a-reich/32/5885_2.png) [@a-reich](https://discuss.python.org/u/a-reich)\ **Post date:** [May 23, 2025, 1:34pm UTC](https://discuss.python.org/t/is-free-threading-our-only-option/91775/73 "2025-05-23T13:34:10Z")
> [@methane](#): > > **Per-interpreter GIL** is very similar to multi-processing, except that it runs within a single process. Even if you simply want to use multiple cores, you have to load the entire application for each interpreter. Resource sharing is difficult too. Isn’t this kind of understating the capabilities that have been implemented by @eric.snow for PEP 734? It implies that sharing has the same limitations as multiprocessing. Yes, currently sharing is limited at a basic level to certain primitive types, but those types can be shared without duplicating memory. Also, anything supporting the buffer protocol can be shared as memoryviews - and this has very low latency regardless of whether the buffer is very large! (It also omits mention of the Project Verona team’s [proposal](https://discuss.python.org/t/adding-deep-immutability/92011) at the language summit to add immutable conversion of objects and ability to share them across interpreters.) --- _[View the full topic](https://discuss.python.org/t/is-free-threading-our-only-option/91775)._