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

Nick Coghlan ncoghlan at gmail.com
Sun May 16 23:12:14 CEST 2010


Bill Janssen wrote:

As far as I'm concerned, just tying all of the program's threads to a single core would be fine, though I imagine others would differ.

Which can be done through the OS tools for setting an application's CPU affinity.

Fixing the Python thread scheduling is only necessary if we want to be able to exploit the extra power of those cores rather than forcing reversion to single core behaviour.

Note that I'm not opposed to fixing it, and the discussion in the tracker issue over Nir and Dave's different approaches to the problem looks interesting.

The release schedule, and labelling things as "release candidates" or not, are all under our control. Nothing is "too late". And there's always Python 2.8 :-) . But I'd consider this a bug in the threading library, not some unmotivated blue-sky change to the GIL.

Yes, but if we never said "too late" we'd never ship anything :)

And you do have a reasonable case for considering this a bug, but it wouldn't be the first time we've escalated bug fixes to "new feature" level simply because they had a relatively high impact on core parts of the code.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia



More information about the Python-Dev mailing list