A Jesse Jiryu Davis Grok the GIL Write Fast And Thread Safe Python PyCon 2017

"Speaker: A. Jesse Jiryu Davis
I wrote Python for years while holding mistaken notions about the Global Interpreter Lock, and I've met others in the same boat. The GIL's effect is simply this: only one thread can execute Python code at a time, while N other threads sleep or await network I/O. Let's read CPython interpreter source and try some examples to grok the GIL, and learn to write fast and thread-safe Python.
Slides can be found at: speakerdeck.com/pycon2017 and github.com/PyCon/2017-slides"

[@MrBulbusOculi]

2:30

[@melizeche]

thanks!

[@RoamingAdhocrat]

Seriously why are so many uploads like this

[@arjunkirpal9776]

awesome! thanks for the talk!

[@ThrashAbaddon]

Superb talk. Thank you Jesse :)

[@pydevteam9745]

Amazing! Thank you!

[@chiragshahckshhh9696]

Amazing talk.

[@XieQiu]

really great talk

[@cinedoodles905]

Great talk. Thank you

[@mdesm2005]

Nice. And I like "dumb" examples, they let you focus on the principle that's being communicated. Question, how does the OS (linux, Windows) determine what core to run the forked process in ? Is the forked process guaranteed to run in a different core (assuming a muli core CPU)?

[@Cat_Stevens]

It differs a lot between operating systems, because of course task scheduling is the job of the kernel. For Linux, take a look at stackoverflow.com/q/23259881/4532996. On Windows, it's much harder to know, because of course it's closed source, but the most cache friendly decision is usually chosen in both cases. However, on Windows, Darwin (Mac OS X's BSD-like kernel), and Linux, the chance to be moved to a new CPU core is affected by the parent process's "nice" status (see en.wikipedia.org/wiki/Nice_(Unix) and en.wikipedia.org/wiki/Processor_affinity )

[@mdesm2005]

thank you :)

[@redberries8039]

It doesn't matter if you're the original or the clone ...what matters is who grabs the bank account first, the wife can wait ..she will follow the money