[Python-Dev] Threading in the Standard Library Tour Part II (original) (raw)
Tim Peters tim.peters at gmail.com
Mon Aug 16 04:05:00 CEST 2004
- Previous message: [Python-Dev] Threading in the Standard Library Tour Part II
- Next message: [Python-Dev] Threading in the Standard Library Tour Part II
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I agree it would help to say more about threading pragmatics. It's hard to say anything true, though . 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>.
- Previous message: [Python-Dev] Threading in the Standard Library Tour Part II
- Next message: [Python-Dev] Threading in the Standard Library Tour Part II
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]