On 19May2013 03:02, Carlos Nepomuceno <carlosnepomuc...@outlook.com> wrote: | Just been told that GIL doesn't make things slower, but as I | didn't know that such a thing even existed I went out looking for | more info and found that document: | http://www.dabeaz.com/python/UnderstandingGIL.pdf | | Is it current? I didn't know Python threads aren't preemptive. | Seems to be something really old considering the state of the art | on parallel execution on multi-cores. | What's the catch on making Python threads preemptive? Are there any ongoing projects to make that?
Depends what you mean by preemptive. If you have multiple CPU bound pure Python threads they will all get CPU time without any of them explicitly yeilding control. But thread switching happens between python instructions, mediated by the interpreter. The standard answers for using multiple cores is to either run multiple processes (either explicitly spawning other executables, or spawning child python processes using the multiprocessing module), or to use (as suggested) libraries that can do the compute intensive bits themselves, releasing the while doing so so that the Python interpreter can run other bits of your python code. Plenty of OS system calls (and calls to other libraries from the interpreter) release the GIL during the call. Other python threads can run during that window. And there are other Python implementations other than CPython. Cheers, -- Cameron Simpson <c...@zip.com.au> Processes are like potatoes. - NCR device driver manual -- http://mail.python.org/mailman/listinfo/python-list
