Antoine Pitrou <solip...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com