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

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