Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Kevin Conway <kevinjacobconway@gmail.com>
Newsgroups: comp.lang.python
Subject: Re: asyncio - run coroutine in the background
Date: Tue, 16 Feb 2016 13:22:36 +0000
Lines: 60
Message-ID: <mailman.166.1455628969.22075.python-list@python.org>
References: <mailman.131.1455518141.22075.python-list@python.org> <8737sumpjl.fsf@elektro.pacujo.net> <mailman.132.1455520607.22075.python-list@python.org> <87h9ha8lt0.fsf@jester.gateway.pace.com> <CAPTjJmoWUDfcOe3OCaMK7=zDtW3QzS+7hqUG6DoYZ2AbqzJBUw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
In-Reply-To: <CAPTjJmoWUDfcOe3OCaMK7=zDtW3QzS+7hqUG6DoYZ2AbqzJBUw@mail.gmail.com>
Precedence: list
Xref: csiph.com comp.lang.python:103005

If you're handling coroutines there is an asyncio facility for "background
tasks". The ensure_future [1] will take a coroutine, attach it to a Task,
and return a future to you that resolves when the coroutine is complete.
The coroutine you schedule with that function will not cause your current
coroutine to wait unless you await the future it returns.

[1]
https://docs.python.org/3/library/asyncio-task.html#asyncio.ensure_future

On Mon, Feb 15, 2016, 23:53 Chris Angelico <rosuav@gmail.com> wrote:

> On Mon, Feb 15, 2016 at 6:39 PM, Paul Rubin <no.email@nospam.invalid>
> wrote:
> > "Frank Millman" <frank@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
>