On Mon, Feb 15, 2016 at 6:39 PM, Paul Rubin <no.email@nospam.invalid> wrote: > "Frank Millman" <fr...@chagford.com> writes: >> The benefit of my class is that it enables me to take the coroutine >> and run it in another thread, without having to re-engineer the whole >> thing. > > Threads in Python don't get you parallelism either, of course. >
They can. The only limitation is that, in CPython (and some others), no two threads can concurrently be executing Python byte-code. The instant you drop into a C-implemented function, it can release the GIL and let another thread start running. Obviously this happens any time there's going to be a blocking API call (eg if one thread waits on a socket read, others can run), but it can also happen with computational work: import numpy import threading def thread1(): arr = numpy.zeros(100000000, dtype=numpy.int64) while True: print("1: %d" % arr[0]) arr += 1 arr = (arr * arr) % 142957 def thread2(): arr = numpy.zeros(100000000, dtype=numpy.int64) while True: print("2: %d" % arr[0]) arr += 2 arr = (arr * arr) % 142957 threading.Thread(target=thread1).start() thread2() This will happily keep two CPU cores occupied. Most of the work is being done inside Numpy, which releases the GIL before doing any work. So it's not strictly true that threading can't parallelise Python code (and as mentioned, it depends on your interpreter - Jython can, I believe, do true multithreading), but just that there are limitations on what can execute concurrently. ChrisA -- https://mail.python.org/mailman/listinfo/python-list