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

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