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

[Bill Janssen]

Antoine Pitrou <solipsis at pitrou.net> wrote:

> Well, 2.7rc1 is scheduled in less than three weeks now. IMO any patch
> changing fundamental threading properties is a no-no (even the processor
> affinity proposal).

Unfortunately, our "fundamental threading properties" are broken for
multicore machines.  And multicore seems to be the wave of the future.

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.

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

> Someone had tried to backport the new GIL to 2.7 (there's a tracker
> issue for it, I'm too lazy to search right now), but it was concluded
> that compatibility requirements for Python 2.x (compatibility with
> various legacy threading libraries) made things too complicated and
> tedious.

http://bugs.python.org/issue7753, from January.

I've read through that issue (several times), and I have to say that I
wind up gnashing my teeth each time.  Here's a fix that's rejected
because it "only" supports NT and POSIX threads.  What percentage of
Python use cases do those two threading systems cover?  Do we know?

If by "compatibility requirements" you mean that new releases of Python
should run on antique systems just as the older releases did, that's
satisfied by the issue's current state, you're right.  On the other
hand, to me that seems an odd goal to prioritize.  After all, the older
releases are still there, for that antique system.

Nor do I see an answer to Russ' final question:

``What if, as you proposed earlier, the patch were to leave the old
behavior if the threading model on the given platform were not
supported?''

> > > There's some code which releanses 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.
> 
> "Letting experts do optimizations" is a regression, though, because
> right now you don't have to be an expert to take advantage of such
> optimizations (just run a separate thread doing e.g. some zlib
> compression).

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 -- you have to find the right
patch in issue 7753, apply it to the sources, build a custom python, and
use it.  Whether or not use explicitly know you are using threads
(because some other package may be using them under the covers).

Bill