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

Bill Janssen janssen at parc.com
Mon May 17 18:05:03 CEST 2010

Antoine Pitrou <solipsis at pitrou.net> wrote:

On Sun, 16 May 2010 15:13:44 PDT Bill Janssen <janssen at parc.com> wrote: > > So the patch to the threading code would presumably, for those OSs where > the capability exists, try to put all created threads in the same > affinity set.

This is not really a good idea.

Yes, fixing the GIL for multicore in 2.7 would be a better idea, IMO. But that might be too large a change.

There's some code which releases the GIL, precisely so that you can run several threads (computations) at once.

If they can get hold of the GIL in the first place! Yes, you'd want to be able to "unbind" threads if you knew what you were doing, so that they could run on other cores, and you'd want a switch to disable the affinity mechanism entirely. But I'd be happy to have things in the naive case run as well as they do on single-core machines, and let experts do optimizations.

If you aren't too concerned with interactivity, you can increase sys.setcheckinterval() to alleviate the problem on 2.x.

Unfortunately, many use cases might well be concerned with interactivity. Things like event-processing loops.

Bill

More information about the Python-Dev mailing list