3 ms·
Interesting, but mostly pointless IMHO. Python can't do proper multithreading because of the GIL (excluding Jython and IronPython, of course), hence using thre
by alanfranzoni 9y ago
Interesting, but mostly pointless IMHO.
Python can't do proper multithreading because of the GIL (excluding Jython and IronPython, of course), hence using threads in Python doesn't benefit anyone.
If you want to learn how to do multithreaded programming, pick a language where multithreading actually works - Java would be a good example. Or just take a look at a POSIX threads tutorial.
If you want to handle concurrency in Python, ignore multithreading. Take a look at the multiprocessing module, or, for a different paradigm, at asyncio or Twisted.
- js2 9y agoWell this isn't the full story. If you have an I/O bound work-load, say you want to parallelize HTTP requests, threads work just fine.
- alanfranzoni 9y agoIf you have an I/O bound workload, a reactor or proactor approach are way better. No dealing with locks, race conditions, etc. I never said it's wrong, it's just pointless. In Python, there's always a better alternative to multithreading which has no shortcomings.
- Erwin 9y agoThat's assuming all the IO you can block on HAS support for non-threaded concurrency. Things that wrap C libraries may support threads, but not the reactor-of-the-day (twisted? tornado? etc.)
- vsajip 9y agoIf your threads are doing I/O rather than computation, then the GIL is less of an issue because it will be released until an I/O operation completes. It's only for threads which contend for the CPU that the GIL is a problem.