[Python-Dev] Fixing the GIL (with a BFS scheduler) (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Mon May 17 22:20:14 CEST 2010

Not fixing this is a big problem. It relegates the only Python which will be usable by many many people for many years, 2.x, to a toy language status on modern machines. It will have threads, but the use of them, either directly or indirectly by modules you may import, may cause unpredictable performance problems.

People may disagree with this characterization, but if we take that for granted, then, yes, we are willing to accept that as the state of things for the coming years.

People running into these problems will have a number of choices to them: switch operating systems (i.e. drop OSX for something that actually works), switch programming languages (i.e. drop Python for something that actually works), switch application architectures (i.e. drop threads for something that actually works), switch to 3.x, or just accept the problem, and hope that the system will find something else to do while switching Python threads.

I'd hate to let a fundamental flaw like this go through simply because someone somewhere somewhen set a completely synthetic deadline.

No, it's not like that. We set the deadline so that we are able to cancel discussions like this one. It would be possible to change the schedule, if we would agree that it was for a good cause - which we don't.

If threading performance wasn't broken on multicore, I'd agree with you. But right now, everyone has to be an expert just to use Python 2.x effectively on modern multicore hardware

Not at all. Just use the multiprocessing module instead, and be done. It's really easy to use if you already managed to understand threads.

Regards, Martin

More information about the Python-Dev mailing list