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

Reply via email to