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

["Martin v. Löwis"]

> 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.

People may disagree with this characterization, but if we take that
for granted, then, yes, we are willing to accept that as the state
of things for the coming years.

People running into these problems will have a number of choices to
them: switch operating systems (i.e. drop OSX for something that
actually works), switch programming languages (i.e. drop Python for
something that actually works), switch application architectures (i.e.
drop threads for something that actually works), switch to 3.x, or
just accept the problem, and hope that the system will find something
else to do while switching Python threads.

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

No, it's not like that. We set the deadline so that we are able to
cancel discussions like this one. It would be possible to change the
schedule, if we would agree that it was for a good cause - which we don't.

> 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

Not at all. Just use the multiprocessing module instead, and be done.
It's really easy to use if you already managed to understand threads.

Regards,
Martin