3 ms·
I don't think the blog you cite backs up your claim of "it's still really easy to run into race conditions". The author literally says: "This was actually pret
by asvitkine 3y ago
I don't think the blog you cite backs up your claim of "it's still really easy to run into race conditions".
The author literally says: "This was actually pretty hard to discover. The first few experiments failed, because Python is pretty smart about when it runs each thread."
But I think the main way the GIL protects inexperienced users is that its presence has the effect that Python code using the threading APIs is very uncommon, since those APIs don't currently provide parallel computation (only parallel IO). So inexperienced users are protected due to 99% of Python programs not using multithreading as a result (and so likely the one they're developing also doesn't), whereas this will presumably change when the limitations imposed by the GIL go away.
- mlyle 3y ago> I don't think the blog you cite backs up your claim of "it's still really easy to run into race conditions". > The author literally says: "This was actually pretty hard to discover. The first few experiments failed, because Python is pretty smart about when it runs each thread." I completely disagree here with your reading. Rare race conditions are much worse than races you trip over frequently.
- n2d4 3y agoMore precise wording would've been: "It's still really easy to write code that runs into race conditions". The race conditions are rare, but code that (rarely) causes them isn't.