Earlier quoted context omitted.
Well this release will break any code that uses threads. The goal of this particular release is to work for thread-free programs.
How do single-threaded programs benefit from a lack of GIL?
They don't.
gh-116167: Allow disabling the GIL
11–20 of 259 posts
Re: gh-116167: Allow disabling the GIL
#12Re: gh-116167: Allow disabling the GIL
#13Re: gh-116167: Allow disabling the GIL
#14While the title is correct, it is a bit misleading, because disabling the GIL breaks the asyncio tests. It's like saying the engine can be removed from my car. Sure, it can, but the car won't work.
Well this release will break any code that uses threads. The goal of this particular release is to work for thread-free programs.
Really, any code? I thought they were adding fine-grained locks to the python objects themselves? Are you saying that if I share a python list between two threads and modify it on one and read it on the other, I can segfault python?
Re: gh-116167: Allow disabling the GIL
#15While the title is correct, it is a bit misleading, because disabling the GIL breaks the asyncio tests. It's like saying the engine can be removed from my car. Sure, it can, but the car won't work.
Well this release will break any code that uses threads. The goal of this particular release is to work for thread-free programs.
Couldn’t it work if each threads only touch thread-specific data structures?
Re: gh-116167: Allow disabling the GIL
#16Although this is nice, the problems with the GIL are often blown out of proportion: people stating that you couldn't do efficient (compute-bounded) multi-processing, which was never the case as the `multiprocessing` module works just fine.
`multiprocessing` works fine for serving HTTP requests or do some other subset of embarrassingly-parallel problems.
Re: gh-116167: Allow disabling the GIL
#17Earlier quoted context omitted.
Well this release will break any code that uses threads. The goal of this particular release is to work for thread-free programs.
How do single-threaded programs benefit from a lack of GIL?
They don't benefit much from a lack of GIL, perhaps a small reduction in overhead. This feature is a first step towards being able to disable the GIL completely. It is intended to be implemented in a very conservative manner, bit by bit and so for this first step it should work for thread free code.
Re: gh-116167: Allow disabling the GIL
#18Earlier quoted context omitted.
Well this release will break any code that uses threads. The goal of this particular release is to work for thread-free programs.
Really, any code? I thought they were adding fine-grained locks to the python objects themselves? Are you saying that if I share a python list between two threads and modify it on one and read it on the other, I can segfault python?
With this particular release, yes it will segfault. But down the road what you state is correct, this is just a first step towards that goal.
Re: gh-116167: Allow disabling the GIL
#19Although this is nice, the problems with the GIL are often blown out of proportion: people stating that you couldn't do efficient (compute-bounded) multi-processing, which was never the case as the `multiprocessing` module works just fine.
Managing processes is more annoying than threads, though. Incl. data passing and so forth.
Re: gh-116167: Allow disabling the GIL
#20Earlier quoted context omitted.
Well this release will break any code that uses threads. The goal of this particular release is to work for thread-free programs.
How do single-threaded programs benefit from a lack of GIL?
Disabling the GIL can unlock true multi-core parallelism for multi-threaded programs, but this requires code to be restructured for safe concurrency, which isn't that difficult it seems:
> When we found out about the “nogil” fork of Python it took a single person less than half a working day to adjust the codebase to use this fork and the results were astonishing. Now we can focus on data acquisition system development rather than fine-tuning data exchange algorithms.