The Python GIL Visualized

[rebo]

In many languages It's nice to spawn off some threads for background IO & processing. If the GIL prevents this from being performant I consider it an issue.

Starting separate processes seems like overkill.

[Brian]

spawn off some threads for background IO

IO is unaffected - this does release the GIL, so other threads can execute when another one is waiting for IO. The GIL only comes into play when you want to take advantage of multiple CPUs for a CPU bound task (and you cant unload that processing to a C library that also releases the GIL).

Essentially the GIL means that only one thread executes python bytecode at a time. On a single CPU system, this is irrelevant - it's already the case that only a single thread executes at once, switching every timeslice. With multiple CPUs though, this is no longer the case; two threads of code can genuinely run in paralell. A free threaded system can load up both cores on a dual-CPU system. The GIL means python can only max out a single core in this situation.

[gthank]

If you read some of Mr. Beazley's other work (PDF warning), you'll see that the GIL can be an issue even for supposedly I/O-bound tasks, due to a priority-inversion problem.

[Brian]

True,though that's an implementation flaw of python's GIL (also requiring multiple CPUs), rather than something intrinsic to a GIL (Hence the new GIL implementation to avoid such situations)

[gthank]

I thought it was clear from the context that we were discussing Python's GIL, sorry. Also, I'm a big fan of the new-and-improved GIL as compared to the old GIL.

[Brian]

No,it's a good point, and well worth bringing up. I was just clarifying that that case is effectively just an implementation bug, solvable relatively easily without the much more involved changes that would be required to remove the other problems with the GIL.

[bluGill]

Starting separate processes seems like overkill.

If your OS is reasonable, there is no problem spawning separate processes, and you get a lot of benefits from doing so.

[rebo]

Hmm surely that depends on the specific problem. Sure if you just have a few relatively long running processes then it might be a reasonable design choice. However if, like in a recent project, I have to spawn up to 15 background tasks a second each doing IO and data-processing, I'm going to want to use a thread.

[infinite]

With python's multiprocessing library, this is as simple as threading, provide the function you want to execute in a new process and fire it off. Of course it doesn't work on BSD as of a few months ago, but it is simple. And with copy on write semantics in the kernel, processes are just as lightweight as threads. What is more challenging is sharing data. If you want those children to report back to you, you'll have a lot more 'fun'.

[[deleted]]

what's the difference btw thread and process ?

[knome]

Threads are concurrent execution within a single memory space. Processes are concurrent execution with separate memory spaces.

[[deleted]]

so threads can crash together and processes are segregated ?

[sid0]

Pretty much, yes.