I agree it would help to say more about threading pragmatics. It's hard to say anything true, though <wink>. I'll just pick on this: [Raymond Hettinger] > ... > And, its overhead decreases total application performance. Also, > multiple processors cannot boost performance because Python's > Global Interpreter Lock (GIL) precludes more than one thread > from running in the interpreter at the same time (this was done to > simplify re-entrancy issues). CPython's threading was really designed to allow I/O to proceed in parallel with one thread of Python computation. If used for that purpose, it's not true that total app performance decreases, nor is it true that performance can't improve on a multi-CPU box. Performance can increase significantly in that case, and that's the prime use case for *practical* threading in Python (that's why the GIL is released around virtually all C-level I/O calls -- I/O concurrency is the use case Guido cared about). Given experience with Zope and ZEO, I'd also add about 10 pages explaining that trying to mix asyncore with threads is legally sufficient evidence of insanity <0.9 wink>.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4